Jeff's Blog
Musings about software development, Java, OO, agile, life, whatever.I post occasionally to JavaRanch, a "friendly" forum (it's policed by moderators who cleanse any material deemed offensive). JavaRanch features a book-of-the-week discussion and giveaway. This week, it's a pitch for the book, Next Generation Java Testing. The book so far appears to largely be a pitch for TestNG and an expected couple of rants against JUnit (version 3.8, for whatever odd reason, and not version 4) and TDD. I stopped reading it for now (I'll finish it later) because I found Lasse Koskela's book Test Driven more useful.
As expected, the JavaRanch discussions contain some allusions to the fact that it doesn't matter whether or not you write (unit) tests first or last. I've written elsewhere on this subject many times, so I'll add only a brief thought or two here.
I suppose it doesn't matter, from a conceptual standpoint, if you do test firsts or tests after if you are an experienced professional developer. If you are good at design and structuring your code well, then there's no reason you shouldn't be able to write as many useful tests after you've already built the code.
But that's not what really happens. In the real world**, 8 out of 10 developers aren't so experienced or professional, and so most don't care enough or know enough about design to structure their system right. And as soon as someone says, "you don't really have to write tests for everything, and they can break and that's ok," the 80% end up thinking that these unit tests are largely a waste of time. So they--the developers and the tests--don't get better.
The other reality is of course time. Without a disciplined approach, deadlines always get in the way of tests. Interruptions push unit tests outward, and they just don't get done.
I believe that test-after is only for the true software development master who is close to expert level. For anyone else, it's a recipe for wasted time and frustration. A better investment would be in automating your acceptance criteria.
That's opinion. Test-after is unscientific and undisciplined, and that's fact. I'm willing to accept that there may be something better, but test-after when-you-feel-like-it-and-can-figure-out-how-to-do-it is not it, and TDD is closer to following a scientific method. That too is fact. I'd rather look to advance the craft than make excuses why I'm too set in my ways to change.
** Sorry Tim.
I have noticed that if *I* write the tests last, I don't write the tests to spec, but to code. Likewise this applies to code I've seen others write. There really isn't very much need for me to prove that the compiler works, ie that the code does what the code as-written does. I find in my experience that working the other way takes me in slightly different directions.
If the code would come out the same, and the tests were the same, then it wouldn't matter. As they do not, it apparently does matter.
On that point, +1.
Aren't you supposed to forgive others when they ask? :-)
Links to this post:
<< Home
Archives
February 2004 March 2004 May 2004 September 2004 October 2004 January 2005 February 2005 September 2005 October 2005 November 2005 December 2005 January 2006 February 2006 March 2006 June 2006 August 2006 January 2007 February 2007 March 2007 April 2007 September 2007 October 2007 November 2007 December 2007 January 2008
