Blog of Object Mentor, where Robert "Uncle Bob" Martin and colleagues wrote on test-driven development and software craftsmanship.
HN commenters link it in TDD debates, one saying "TDD Derangement Syndrome" made them least skeptical of TDD and another pointing to the nuance in "TDD Triage".
Nice article.. some examples would be helpful in understanding the author's thesis.
"I believe tests should be written in the language most natural for the problem" - I agree with this. However, to assume natural language is the most fit expression I believe is a jump. Natural language is laden in ambiguity to the point where it misses out on creating specifications in a concise way.
I tend to drift towards the field of thought that BDD should be used to constrain the spec - purposely eliminating ambiguity. I think this is the real opportunity in BDD. This article (http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd) illustrates the point well - making BDD specs analogous with a DSL described by finite state machines. "(BDD) connects the human concept of cause and effect, to the software concept of input/process/output".
So, in this sense using BDD tools like cucumber for expressing natural language can possibly bypass the opportunity to constrain the spec by using constrained natural language or DSLs that best describe the problem domain more explicitly.
Another, similar take on this idea is this article, written in 2007:
Code is a Liability
http://blog.objectmentor.com/articles/2007/04/16/code-is-a-liability
Excerpt: "Code size reduction is a very good thing. I want the simplest, the smallest, the least code possible, with the least risk of breaking something else in the system. I don’t want big functions that touch everything in sight. I don’t want long complicated blocks of if/else statements. I don’t want monster functions which conglomerate dozens of operations in a single, fat interface. Shallow is good. Short is good. Less code is good. More code is a liability. This isn’t about typing less, it’s about owning less."
Have you read Bob Martin's "TDD Triage"? It offers a lot more nuance than you might suggest: http://blog.objectmentor.com/articles/2009/10/08/tdd-triage
> Any worthwhile development practice must have objectively measurable results....
I thought you were asking for objectively measureable results in isolation. You'll still have terrible trouble trying to isolate a single variable (and good luck with a control group for a creative design activity!), but I suspect you can get decent results by measuring the cost of a change, the correctness of a change, and the amount of rework in a change when using TDD.
Hm, makes me think of http://blog.objectmentor.com/articles/2008/06/22/observations-on-test-driving-user-interfaces .
It sounds... scary. Like it will work well enough at first, and then explode when someone changes their desktop theme (especially icon theme), or wants to upgrade to a new version of whatever. Treating things as change-controlled APIs when they aren't just seems dangerous. Still I guess there's at least some amount of change control coming from platform conventions and human interface guidelines, and this comes closer to operating at the correct level of abstraction to benefit from that.
I always try to keep in mind that A Mess is not a Technical Debt[1], and that when you keep that in mind you can do it intentionally[2]. Which is particularly useful when you are more interested in learning[3] about a problem (like building a MVP) than when you are in solving it[4].
[1] http://blog.objectmentor.com/articles/2009/09/22/a-mess-is-not-a-technical-debt
[2] http://martinfowler.com/bliki/TechnicalDebt.html
[3] http://www.ashmaurya.com/2011/06/your-product-is-not-the-product/
[4] http://www.threeriversinstitute.org/blog/?p=251
If you're a compiler type person, Treetop ( http://treetop.rubyforge.org/ ) and Polyglot ( http://polyglot.rubyforge.org/ ) are amazingly cool libraries.
The Case gem (some information here: http://blog.objectmentor.com/articles/2009/03/16/tighter-ruby-methods-with-functional-style-pattern-matching-using-the-case-gem ) for pattern matching is also great, especially if you're dealing with large S-exp structures for compilation. After discovering a few of these libraries, Ruby has become my de facto compiler language.