I was watching InfoQ video where Robert C. Martin and Jim Coplien talked about TDD, Design-by-contract, architecture and many other issues.
One of Bob's arguments was that
A test driven developer does not write a line of production code until he has written a failing unit test, and no production code can be written until there is a failing unit test.
it is irresponsible for a developer to ship a line of code he has not executed in a unit test.
I think that Bob's view on TDD and unit testing is a way too narrow. I'm slightly annoyed that people don't realize that the real value of TDD and unit testing will emerge weeks, months or years after the code has been written. Couple of months ago I read a Michael C. Feathers's book Working Effectively With Legacy Code. He says that
Legacy code is simply code without tests.
Big part of software development is to maintain existing applications and add new features into them. If that code does not have unit tests, it's legacy code. Even if it was written yesterday. TDD is a great way to prevent your code from changing into legacy code. When you are tweaking legacy code, you probably can't use TDD very effectively, but still you can and should try to get that code into a test harness. Why? The purpose of those tests is not TDD. The purpose is to create tests that verify current behavior and create a safety net for you. After your changes those tests should still pass. If they don't, you've broken something.
TDD implies tests, but tests don't imply TDD.
No comments:
Post a Comment