Whatever your stance on the merits or pitfalls of Test Driven Development, I think it’s worthwhile and educational to pay attention to a discussion that’s going on lately.
Testing is crucial. But is unit test focused TDD the right path?
I care about the conversation about TDD because I see serious flaws in the conventional understanding of TDD.
Much of the current view of TDD includes:
- Units are tested in isolation of the rest of the system.
- Unit tests are more important than any other form of testing.
- A “unit” is a class or a function. Nothing larger is a “unit”.
- If you test more than one class, that’s an integration test.
- If you test from the API with all resources, that’s a system test. Let QA deal with that later. Isn’t that exactly where waterfall failed?
- You can’t write any production code without a failing test.
- You have to write only one test at a time, and it must fail.
- Tests have to be fast.
- Therefore, they cannot touch hardware, the file system, other services, or database.
- Tests should be short.
All of this rubs me the wrong way.
I’ll get to my thoughts later, but my concern about this cemented view of TDD caused me to be very interested in the current talks.
On to the discussion
I came in after the 2nd video, while doing research on Agile and TDD.
I’m not sure if the order matters, but here’s a list of what I know about the discussions.