TDD Next Year
code reviews, software development, test driven development
I had two major practices to put in place to improve our overall software development for this fiscal year.
- Implementing Test Driven Development with a target of 70% unit test coverage.
- Implementing frequent, lightweight code reviews.
Easy enough, on number two we’ve been fairly successful and will continue to tighten things up over the next year. Crucible has proved to be a good lightweight tool to help enable this.
On number one I suspect we’re at the same place a lot of development shops end up especially if they aren’t already XP shops. We’re doing a bit of TDD, but the bulk of the unit tests are written after the code sometimes days or weeks after the code. Thus we lose a lot of the design benefit. As a bonus it feels more like a chore when you write the tests later.
On a positive note, we’ve come a long way and the developers see many of the benefits of having a good set of tests around your code. And all pretty much all of the code developed this year had 70% or greater test coverage.
Next year is likely to see another goal of going from unit testing to TDD.
Ed Gibbs @ September 18, 2006
When your teams are using TDD in a disciplined way I think it will encourage them to check in more frequently.
Secondly, I wonder why you are setting a numerical goal of 70% test coverage as an indicator of whether TDD is being used well. When you use TDD rigorously, you (almost) don’t have to worry about “coverage” as such.
Also, it seems more important to ensure you’re testing the right things than just to hit a coverage target. TDD should help with that.
Beware of the trap of developing to satisfy the coverage tool. I recently saw an example of how someone had contrived a way to make a unit test exercise the generated code under the covers of a Java Enum. They went to a fair amount of trouble to do it, but what’s the value? They’re only testing Java “plumbing”, not application code. They wanted to get the coverage tool to show 100% coverage. I guess they succeeded, but…?
Are your code reviews including unit tests?
Many “test-after” unit tests are rather anemic, and in my experience code reviews that include the unit tests often end up requiring the programmer to do more thorough unit testing.
And if the unit tests are hard to write, that indicates the design of the code-under-test isn’t good enough.
‘When your teams are using TDD in a disciplined way I think it will encourage them to check in more frequently.’
Agreed, we don’t see this issue much on the projects where they’ve been doing TDD and unit tests longer. Still I have some developers who are coming out of hardcore waterfall environments and are still adjusting to source control in some ways.
The 70% number on coverage was merely to draw a line in the sand to help enforce the idea that all developers would be writing unit tests. It’s not perfect, but it’s worked pretty well as a supporting practice. On one team they even asked to have the number moved up to justify to their team why they were spending time writing ‘tests’. When everything becomes second nature the coverage target will be pretty unimportant.
‘Are your code reviews including unit tests?’
Yes, but not explicitly which was probably a mistake. As we’ve been getting started I’m almost always one of the reviewers and I make sure to look at the unit test for the code being reviewed first. On one project that’s led them to state that they need to start reviewing their tests. We’re still not real sophisticated on our unit tests and they sometimes contain a lot of obvious refactoring targets and minimal negative scenario test cases.
The unit tests aren’t too hard to write unless they involve JSF at this point and then they’re messy because of all the setup neccessary to create the JSF specific contexts.
Thanks for all the feedback though.