This has turned into an unconstructive argument and for whatever reason we don't seem to be communicating clearly. Shame as I (and probably most people on here) only want to help. You seem to be reacting quite strongly to my thoughts - not sure why.
If I may, I will just make/rephrase two points: - I think you would find value in watching Rick Hickey's videos on "Simple Made Easy" and also the one where he talks about "Hammock Driven Development". - when I started using Clojure I immediately looked for equivalents of all the supporting infrastructure I used in good old Java land. I have no idea of your situation, but if you are there you have a wonderful opportunity to re-examine and build up a whole new toolchain/approach to development that IME is significantly lighter and more powerful. Peace. On Tuesday, 4 February 2014 13:49:49 UTC, Aaron France wrote: > > 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 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.
