3 ms·
I'm not sold completely on TDD. Part of me think that TDD is a necessary evil. Some organizations have the resources to hire many QAs that might help to reduce
by hello_moto 16y ago
I'm not sold completely on TDD. Part of me think that TDD is a necessary evil. Some organizations have the resources to hire many QAs that might help to reduce the number of unit-tests. I'm not saying that is the most cost effective way to go.
Also, if the programmers words can be trusted (that their code is unit-testable, instead of highly-coupled, lots of dependency cycle, etc), writing unit-test last would be alright as well.
- Silhouette 16y agoFWIW, I think the most important thing here is not to confuse use of unit tests with the adoption of TDD. The former does not imply the latter: you can write unit tests after you write your code, or even before/during writing code for that matter, without being test-driven in your approach. I have yet to see any credible study that showed a benefit for TDD and controlled for the use of unit testing as part of a more traditional development process. There is some evidence that, at least for some types of project, TDD has been more successful by some metrics than a heavyweight, waterfall process with no unit testing, but there are usually so many uncontrolled variables involved that it's hard to read much of value into any of those results.