In clojure, generally I've found Unit-tests are often significantly harder to write than the corresponding implementing code, idiomatic code rarely has silly problems, and integration tests are enough to shake out bad behavior.
So, the end result is constraining our codebase at API boundaries with integration tests does pretty well, and unit tests are most likely to get written only when I'm doing something weird and nasty. On Tue, Feb 4, 2014 at 7:14 AM, Korny Sietsma <ko...@sietsma.com> wrote: > My 2c - on my last project it would have been handy to have some test > coverage tools, they can be useful to sanity check your testing. > > However, it's worth noting that compared to a java project, we had far > fewer lines of code, so manually reviewing code for tests was a lot easier. > > And there were cases where some careful integration tests were more useful > than unit testing everything, which ties in to Colin's point I think. And > integration tests tend to break coverage metrics. > > (and I'm not sure how you'd do coverage for macros, but that's probably a > digression) > > - Korny > On 4 Feb 2014 11:23, "Aaron France" <aaron.l.fra...@gmail.com> wrote: > >> >> I don't want to seem rude but I think you've drank a bit too much >> kool-aid. >> >> 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. >> >> 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. >> >> 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 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. >> > -- > 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. > -- 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.
