4 ms·
Try to double the time you promise to do a feature by saying I need to write tests for it. That, IMO, is the best argument for TDD. By having a process that fo
by SoftwareMaven 14y ago
Try to double the time you promise to do a feature by saying I need to write tests for it.
That, IMO, is the best argument for TDD. By having a process that forces tests first, you never get into the situation where you are cutting critical tests for the schedule's sake.
For me, I ask the question, "Is this code adding more value than other code I could be writing?" If the answer is no, I do something else. Of course, this is completely subjective, but my years of experience count for something.
- Silhouette 14y agoThat, IMO, is the best argument for TDD. By having a process that forces tests first, you never get into the situation where you are cutting critical tests for the schedule's sake. On the other hand, with a process like TDD you also never get into the situation where you can cut non-critical tests.
- Evbn 14y agoIf the tests aren't critical, is the feature critical?
- Silhouette 14y agoSurely that depends on many factors, just like using any other tool or process? Does each test tell you something valuable? Is the cost of implementing and maintaining that test less than whatever value the test offers? That is, is the test cost-effective? Could you have found the same information more effectively some other way? That is, what is the opportunity cost of writing and maintaining that test?