This in fact happens a lot- QA reports a bug- they fix it, and it breaks something else. Of course my first response is like yours- "if there were tests around that functionality, then we wouldn't have this problem". However, using TDD is being seen as a style difference, and "it's hard to teach experienced developers new tricks".
If they're seeing bugs -- let alone
regressions -- that unit testing would have caught, and that in itself isn't scaring them into writing more unit tests, then I wouldn't call them all that experienced. TDD as such could indeed count as a difference in development style, but requiring tests for such functionality as is testable, and not marking the functionality complete until the test is complete, isn't a style thing, it's a "this is what the quality bar is for check-in" thing. Which is within a project technical lead's mandate.
The problem is that unit testing is not valued by everyone
Yes. Many software bugs are in fact composed of two bugs -- the bug itself, and the bug whereby the test suite didn't find it. There's little point fixing the first without fixing the second while you're there. Of course some projects -- some environments -- are more amenable to testing than others, but it sounds like your one is relatively lucky on that front.
Peter
Previous Topic
Index
