In a recent blog post, Nat Pryce expressed a concern that I’ve long had:
I have observed that few programmers are skeptical enough about the code they write. They focus on success cases, ignore edge cases and error cases, try to bang out as many features as possible, and don’t notice that those features are incomplete or will not work in some situations.
And then Nat goes on to explain how test-driven development can help developers improve their thinking about the tests that they write:
As programmers get more experienced with writing automated tests, they get better at thinking about how their code might fail. That’s because they get plenty of opportunity to observe where their tests are insufficient and think about how to avoid such problems in the future.
I don’t disagree with Nat at all, but I am still concerned that it’s a case of fitting a case of trying to fit a round peg into a square hole: the developer may get better at writing tests, but she’s still a developer, not a testing specialist.
This is, of course, one of the reasons why we perform other types of testing in addition to unit tests. But if we want to make sure unit tests are robust, it seems like we need to involve the testing specialist in some way. And having the developer pair with the testing specialist to review unit tests is the most obvious solution to em. Even if the testing specialist’s skill-reading codes are weak, the developer can at least describe the tests to the testing specialist (If the testing specialist has the skills to write unit tests, having him (help to) write the unit tests would be another alternative).
I’ve pursued this type of pairing a few times, but it has never worked out for more than a couple of weeks. The primary reason for this failure, in my opinion, is lack of buy-in from the developers. They don’t see the value of having a testing specialist review their unit tests, or unit testing just somehow remains the property of the development club.
Any advice or experiences you can share would be helpful.