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? :)
> 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). > 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. 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. 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 other TLAs etc.). 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. > 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.
