On Tue, Feb 04, 2014 at 04:18:30AM -0800, Colin Yates wrote: > Comments in line. > On Tuesday, 4 February 2014 11:23:36 UTC, Aaron France wrote: > > > > > > I don't want to seem rude but I think you've drank a bit too much > > kool-aid. > > > You know the phrase "I don't want to seem rude" doesn't actually do > anything right? :) > >
I genuinely don't want to offend. People allow themselves to become vested in their viewpoint. If that has happened to you, I'm sorry. > > To say that functional programming and war against state means that > > your application doesn't need to be tested thoroughly is a joke. And a > > very bad one. > > > I agree, but who is saying that? I certainly didn't cover how much testing > is necessary. I thoroughly test my Clojure systems using midje, which > regularly rocks my world. My point is that the coverage is much *much* > easier to reason about in FP than in OO (for the reasons I gave). I'm not following how you translate this into information which explains how your system is being tested. > > > > Coverage doesn't just aid you in seeing which parts of state caused > > which branches to be hit, it also gives you notice if there are any > > logical errors in your code which cause the branches to not be hit. > > > And why are those logical errors which cause the branches to not be hit not > immediately obvious? Why do you need a tool to tell you that? I know my > Clojure code has around 100% coverage using white box testing for the > functions and mocking the interactions. And what's the harm in getting this information from an automated tool? With your 20 years industry knowledge you should know that you cannot rely on humans to think and act reliably. It's just not a good way to plan systems. *Especially* when it comes to asking someone how correct their system is. > > I would challenge you to put ego/emotion to one side, stop finding > non-existent points to argue against and re-read my post. By all means > come back and justify why all the points I raised which reduce the need for > coverage are invalid. Don't attribute stupid statements (like 'FP doesn't > need testing') to me - I can come up with my own stupid statements thank > you. You hand waved the need to use tools such as coverage reports simply on the virtue of some hard to quantify statements. I find that unscientific. > > If it helps, my stand point is from 20 years of building non-trivial > Enterprise applications (primarily Java) using the current best of breed > technology stacks (i.e Spring/Hibernate/AspectJ) with the best of breed > process (agile, TDD, DBC, BDD, most otherTLAs etc.). Arguments from authority mean nothing on the internet. > Using Clojure for the past year or so has opened my eyes to exactly > how many problems we solve, and infrastructure we use is to pamper > to complexity introduced by the tool-chain not the problem domain. > I am suggesting maybe coverage tools are one of those. > Coverage helps nothing on its own. It's a tool to aid in knowing which aspects of your system remain untested. It's fine to *believe* you're testing 100% of your system, but how do you actually know this? If you wander into a codebase you're not familiar with, what's the coverage? How do you know you're hitting all codepaths? You just cannot know this without reading all the code and the tests. Coverage helps to discover this information. My point isn't to eschew all other forms of testing in favour of coverage reports but to use them in tandem with the others to aid me in *knowing* which parts of the system are being tested and which are not. Aaron > > > Aaron > > > > On Tue, Feb 04, 2014 at 03:19:05AM -0800, Colin Yates wrote: > > > I don't know. > > > > > > But maybe the lack of coverage tools is itself interesting? My (not > > quite > > > formed/making this up as I go) view is that maybe coverage tools are > > there > > > to address the implicit complexity in other mainstream languages and/or > > to > > > help mitigate the risk of the potentially large and hard-to-identify > > > 'impact analysis' you get in OO systems when you change state. In other > > > words, coverage is necessary because we want to feel safe that all > > > combinations of our code are extensively tested. Why don't we feel > > safe? > > > Because the system is hard to reason about. > > > > > > Functional programming on the other hand is full of much smaller > > discrete > > > and independent chunks of functionality. Ideally these small focused > > > 'bricks' are pure/referentially transparent so the *only* context you > > need > > > when reasoning about them is their parameters and the logic inside. > > > Assembling these bricks introduces interactions that need to be tested, > > > sure, but there are very few 'call this and watch the change > > cascade'/'this > > > code is sensitive (i.e. coupled) to that data over there'. > > > > > > My ramblings are to say, maybe the root cause of coverage tools is to > > solve > > > a problem (hard to reason about systems) which shouldn't be much less of > > a > > > problem in FP when FP is done right. OO + mutable state = hard to > > reason > > > about. FP + immutable state + pure/referentially transparent functions > > = > > > much easier to reason about. > > > > > > Or not. Just my 2 pence :). > > > > > > On Sunday, 2 February 2014 21:34:29 UTC, Aaron France wrote: > > > > > > > > Hi, > > > > > > > > I'm looking for coverage reporting in Clojure. I've been using > > > > Cloverage[1] but I'm just wondering if there are any other coverage > > > > tools? > > > > > > > > Aaron > > > > > > > > > > > > [1] https://github.com/lshift/cloverage > > > > > > > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "Clojure" group. > > > To post to this group, send email to clo...@googlegroups.com<javascript:> > > > Note that posts from new members are moderated - please be patient with > > your first post. > > > To unsubscribe from this group, send email to > > > clojure+u...@googlegroups.com <javascript:> > > > For more options, visit this group at > > > http://groups.google.com/group/clojure?hl=en > > > --- > > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > > To unsubscribe from this group and stop receiving emails from it, send > > an email to clojure+u...@googlegroups.com <javascript:>. > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out.
pgpB7kuqEyTcy.pgp
Description: PGP signature
