|
|
|
|
|
|
by erichmond
3750 days ago
|
|
|
It should be noted that TDD specifically means writing tests before you write application code. For example, at our shop, we don't require devs to do TDD, however we require test coverage. I don't think anyone would argue that writing tests at all is a bad idea, I think the debate is whether or not your tests should drive your application code. |
|
|
If we're talking specifically about the kind of low-level unit tests required for TDD, that is still an assumption, though not an implausible one.
Even if unit testing is effective by some measure, it takes a significant investment of time to create and run those tests. TDD also constrains the software design and the development process.
Maybe we would do better to remove those constraints and instead spend that time on some other activity? Maybe some form of code review or walk-through exercise would be effective. Maybe we should be writing higher-level tests. Maybe we could formally prove some key parts of our code are correct. Learning new programming skills might stop us making some mistakes in the first place. Maybe we should even be adopting a new language or tool that would prevent some errors from being possible at all by design.
There are many ways we can try to make our code more reliable, and they all have costs, and sometimes they conflict. Even if one of them is better than nothing in isolation, that doesn't necessarily make it the best possible strategy when you consider the alternatives and opportunity cost.