+1 I still force myself to write those tests simply for the confidence they give me in replacing my hack with idiomatic code as I/colleagues get more familiar down the road. I can absolutely see dramatically reducing the number of 'safety rails' type tests pretty soon; most of the code uses the core abstractions. It is quite humbling/interesting how little new code I actually need to write as oppose to picking one/assembling some off the shelf.
On Tuesday, 4 February 2014 12:22:57 UTC, Gary Trakhman wrote: > > 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<javascript:> > > 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...@gmail.com <javascript:>> >> 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 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.
