测试驱动开发的缺点? [英] Disadvantages of Test Driven Development?

问题描述

采用测试驱动设计会丢失什么?

What do I lose by adopting test driven design?

只列出底片；不要列出负面形式的好处.

List only negatives; do not list benefits written in a negative form.

推荐答案

几个缺点(我并不是说没有任何好处——尤其是在编写项目的基础时——它会在结束):

Several downsides (and I'm not claiming there are no benefits - especially when writing the foundation of a project - it'd save a lot of time at the end):

• 投入大量时间.对于简单的案例，您会损失大约 20% 的实际实施，但对于复杂的案例，您会损失更多.
• 额外的复杂性.对于复杂的情况，您的测试用例更难计算，我建议在这种情况下尝试使用将在调试版本/测试中并行运行的自动参考代码运行，而不是最简单情况的单元测试.
• 设计影响.有时设计在开始时并不明确，并随着您的进行而演变 - 这将迫使您重做您的测试，这将导致大量时间损失.在这种情况下，我建议您推迟单元测试，直到您对设计有所了解.
• 持续调整.对于数据结构和黑盒算法，单元测试将是完美的，但对于倾向于更改、调整或微调的算法，这可能会导致大量时间投资索赔是不合理的.因此，当您认为它确实适合系统并且不要强迫设计适合 TDD 时，请使用它.

• Big time investment. For the simple case you lose about 20% of the actual implementation, but for complicated cases you lose much more.
• Additional Complexity. For complex cases your test cases are harder to calculate, I'd suggest in cases like that to try and use automatic reference code that will run in parallel in the debug version / test run, instead of the unit test of simplest cases.
• Design Impacts. Sometimes the design is not clear at the start and evolves as you go along - this will force you to redo your test which will generate a big time lose. I would suggest postponing unit tests in this case until you have some grasp of the design in mind.
• Continuous Tweaking. For data structures and black box algorithms unit tests would be perfect, but for algorithms that tend to be changed, tweaked or fine tuned, this can cause a big time investment that one might claim is not justified. So use it when you think it actually fits the system and don't force the design to fit to TDD.

这篇关于测试驱动开发的缺点?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！