[moe]

My latest irritation is manager types getting too obsessed with Unit testing, it reminds of XML and the way it was abused.

It's a bit of a tangent but I've also observed this. So much that I've started calling it the "cucumber-complex".

Once infected the team not only writes excessive unit-tests to validate things like that a method-call to 'foo' does indeed call the method 'foo'. But they also wrap these unit-tests in quite elaborate parsers in order to "express" them in pseudo-english.

The hilarious (cucumber-specific) aspect is how they usually start by writing their tests in plain RSpec or Test::Unit and then go at implementing the parser to make it "tell a story".

[benjaminwootton]

I wouldn't be so quick to write off Cucumber et al.

A few benefits:

- Sometimes business users will contribute and use these scripts (admittedly in only some teams and less often than supporters would claim);

- They help with analysis and design as you are forced to question exactly what behaviour you would like to acheive;

- They keep the developer focused on the feature rather than, for instance, building some big fully featured class or library which wont be used;

- They encourage outside in testing so you get good but pragmatic testing for features at each layer of the application;

- They act as a free living documentation on the system;

- They are more lightweight than they initially appear.

I would rather have lots of BDD style tests than the silly tightly coupled unit tests loaded with expectations that you describe erlier in your post.

[zem]

the most important bit, i think, is that a cucumber test suite is documentation that cannot go out of date, because if it does your test breaks and you have to fix it, thereby updating the documentation aspect of it.