Update: Martin Fowler pointed to Jeff Langrs response. It seems Cedric did not give us the full picture. I have edited my post accordingly
~~After attending a less than stellar presentation on TDD,~~Cedric Beust confuses TDD with “Agile” and goes on to tell the world that agile is not good. Let’s have a look, shall we?
First of all, tests are not specs. Not even close. Somebody in the audience was quick to give a counter-example to this absurd claim by using a numeric example (‘how do you specify an exponentiation function with a test?’)
I would not use unit tests for specs. Automatic acceptance tests on the other hand is really nice if you have a customer/product owner that will work with you. Now Cedric has previously stated that he does not really care for the labelling of tests (“However, when I write a test, I don’t really care if it’s a unit test or a functional test”) so that of course makes it harder for him.
And hey, testing an exponentiation function? How about providing test data with given parameters and answers? It would be a prime candidate for a FIT-test by the way.
Relying on tests as a design specification is lazy and unprofessional because you are only testing a very small portion of the solution space of your application (and of course, your tests can have bugs).
Why would you only test “a very small portion of the solution space of your application”?
Tests also fall extremely short of having the expressiveness needed to articulate the subtle shades that a real specification need to cover to be effective.
This is my main gripe with Cedrics rant. He seems to be completely oblivious to the great emphasis on customer interaction that agile methods make, which promotes a two way dialogue.
A specification written in a document is a one way communication. Even in high school psychology I learned how much more information was conveyed in a spoken dialogue than in writing.
This claim is part of a broader and more disturbing general Agilist attitude that is usually articulated like ‘Your code is your spec’, along with some of its ridiculous corollaries such as ‘Documentation gets out of date, code never does’.
What is so ridiculous with the last statement? I have never been involved in a large scale project where the documentation did not get out date.
As for the code being your spec: when you have code and documentation, and the latter does not correctly describe the former, it is out of date, which will you trust? And what do you read to know what the real world looks like? Map, meet terrain.
I am currently getting acquainted with a brand new project that is not even very big, and while I understand Java fairly well, there is no doubt in my mind that for ten minutes I spend trying to understand how a certain part of the application works, a five-line comment would have given me this knowledge in ten seconds.
Sure, if it is up to date, which you will have to read the code to find out. My general rule: if you feel the need, comment on why the code does what it does if it is not obvious. If you feel the need to comment on what the code does, the code is not clear enough. Refactor until done.
Very often, Agilists simply forget that their job is to produce software that satisfies customers, not software that meets some golden software engineering scale.
Again, this is simply ridiculous - all agile methods try to get customers as close as possible to produce just what they want. Anyone even remotely knowledgeable with agile methods knows that.
Frankly, it takes all of ten minutes to explain Test-Driven Development to a developer who’s never heard of it: ‘Write a test that fails and doesn’t compile. Make it compile. Then make it
I actually find it quite hard to get developers to grasp TDD; people find testing something that does not exist confusing. This is of course the basis for behavior driven development, but let’s just be happy for Cedric now.
Some might find it picky, but leaving out ‘refactor’ in the TDD loop tells me that you somehow has not grasped the concept completely. But then Cedric might throw in a comment instead :).
‘What should we test now?’ ‘How about: if we pop an empty stack, we get an exception’ <a bit embarrassed> ‘Mmh, no, let’s not do that’ <hand waving, look down at notes and proceeds while happily ignoring the other raised hands>
This is quite easy to test, so I do not see why he could not add it.
Read Jeffs answer
#java
Stack s = new Stack();
try {
s.pop();
fail("Should not get here");
}
catch (Exception e){
//Ignore
}
But I am dead sure Cedric knows this , too bad the presenter did not.
To be honest, I am becoming quite suspicious of Agile practices for that reason: all the presentations I have attended and books that I have read are always using toy implementations as examples. Stack, List, Money, Bowling… enough already!
Ignoring the fact that Cedric again confuses TDD and agile, he does have a point. Too many TDD presentations uses examples that are way too simplistic. They should point out the need of a modular architecture, and the fact that using TDD actually helps you get a clean, high cohesion - low coupling architecture.
And please, avoid smug and useless answers such as: ‘A lot of the classes I have to test are hard to isolate, do you have any advice regarding mocks?’ ‘Well, if you had started with TDD in the first place, you wouldn’t be having this problem today’.
It is certainly not a helpful answer, but it is true nonetheless.
Fundamentally, I am disturbed by the Agilists’ dishonesty when it comes to presenting their arguments. They offer you all these nice ideas such as Test-Driven Development and Pair Programming but they never – ever – disclose the risks and the downsides. To them, Agility is a silver bullet that is applicable in all cases with no compromises.
Just to give one example, “Practices of an Agile Programmer” clearly states that agile is not for everyone.
The truth is that these practices come at a price, and for a lot of organizations, the price gets high very quickly. Agile development will never go far if its proponents keep ignoring these organizations and make condescending comments to its members.
Here Cedric is spot on. Yay!
I like Test-Driven Development. I really do, and I’m fortunate enough to work on a project that lets me use TDD most of the time. But the truth is: at times, I don’t do TDD because implementing a feature quickly is more important than a fuzzy feeling. And I’m also aware that TestNG is an open source project with less than five developers, all of them on the bleeding edge and aware of the latest advances in software engineering. And this is my main beef with Agilists: I strongly suspect that most of them are spending their time on open source projects with like-minded fellows, but none of them have any experience what companies whose survival depends on shipping software have to go through to organize huge code bases growing thousands of lines of code every day under the combined push of hundreds of a developers, all with their personal background, education and bias.
My main beef with people opposing agility is that they basically say that too many of the developers out there are morons who cannot perform unless closely supervised and given clear instructions, and that there is no hope that that will ever change. It is a weird combination of pessimism and elitism
Now Cedric has a history of not liking agile methods, and that is fine with me. Whatever makes him happy. But his retoric in this case is like watching somebody who does not know karate perform a round house kick - lots of power and effort but misses the target completely.