Demonstrating Test-Driven Development and Evolutionary Design in the long run
Download as MP4
Hi Esko, something about this video struck me as the over application of the wrong technique for a worthy problem. You're spending a lot of lines of code automating tests for the build system. This is not free, and comes at a huge cost (every line of code is a maintenance burden -- production /and/ test).As an aside, I'd recommend you drop Maven. I've been using Gradle now, and for the most part have been happy. The build system simplifies dramatically, and you can do your invariance checks much more elegantly as part of the build, rather than with JUnit tests. But this isn't my main point.What I'm really driving at is really just a reiteration of a post-TDD sentiment that I'm excited to see making appearances from notable sources. The last one I've seen was Rich Hickey's "Simple Made Easy" talk. The video's on InfoQ (I highly recommend it). It's a simple message, but it challenges the very nature of how you're coding.The brunt of the message is this -- spend almost all your energy on making the system simple, and be very apprehensive about automating tests around complexity. We've gotten too good at this to the detriment of our architectures (Rich playfully refers to this as "guardrail programming").Concurrency can be hard, but I'd assert we should focus much less on byte-code manipulating tests, and much more on programming with higher levels of abstractions, and certainly with referential transparency as a fundamental tenant.In this regard, I'm really excited about all the work Rich has put into Clojure, especially its "transients" which in my opinion much more elegantly addresses the problem you're dealing with.My point is this. . . we /need/ to reduce our pain thresholds. You say in your video, "Good, now I have tests for the tests." Please stop yourself when you get to this point. This is a smell, and leads to an awful maintenance burden. A programmer I respect likes to point out that every test is a point of coupling in a system we want as decoupled as possible.I bump into your on-line presence a bit these days. For the most part, I like what you advocate. But this video got me concerned.
I started writing a reply, but it became so long that I posted it on my blog: http://blog.orfjackal.net/2011/12/why-use-inferior-tools.html