TDD对于小型项目来说是否过度设计？

Question

TDD对于小型项目来说是否过度设计？

44

我最近一直在阅读关于TDD等方面的文章，但我还不完全看好它。我制作了许多小型爱好项目（只有我一个人），我担心尝试使用TDD是否过度kill掉这些项目。虽然我曾经看到过像三名开发人员一样进行TDD的小型开源项目。（虽然我也看到了一些单人项目也使用TDD）

那么，TDD总是值得做的吗？在什么阈值下才有意义呢？

- Earlz

3

测试、测试驱动开发和单元测试是三个不同的概念。有些应用程序对单元测试毫无益处。并不存在“一刀切”的解决方案、设计或者实践。 - Egor Pavlikhin

很疯狂，大多数人都在缩写TDD，但是在原始帖子中从未将其扩展为“测试驱动开发”（Test-driven development）。 - zanlok

TDD 不仅仅是测试/质量保证，它还可以改进架构（更松散耦合的模块）和可维护性（如果想知道模块做什么以及如何使用它，请阅读模块的单元测试）。 - k3b

17个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Sebastian Hoitz · Answer 1

其实，人数并不是决定TDD是否适用的关键因素（至少您的问题似乎是这样的），而更多的是项目的规模。

TDD的优点在于，你所开发的所有代码都将得到单元测试。这样，在以后进行重构时，你就可以省去很多麻烦。当然，只有在项目规模较大时才真正需要这样做。

- KarlM · Answer 2

在我的经验中，90%的时间那些对其好处持怀疑态度的人并没有尝试过它。以怀疑的心态尝试一下，衡量一下你希望从中获得的收益，在之前和之后进行比较。

我可以指出，在生产环境中发现的漏洞修复所需的时间大大减少，提高了生产力（更快的上市时间），代码质量有所改善（在各种指标方面），与要求的匹配更加紧密（即因要求不清晰而减少重新工作等）。

我“感觉”使用TDD的项目更好，但我是“测试感染者”。使用TDD的项目开发者士气普遍较高，这是一个主观的观点。

如果你没有得到这些结果，就不要使用它。如果你不太关心这些结果，也可以根据自己的感觉使用TDD或不使用。

TDD有一个学习曲线。如果你不愿意付出努力认真尝试，就不要费心了。

小项目是一个很好的方式，可以在不冒太多风险的情况下认真尝试。

- lance · Answer 3

当你意识到写代码可能会出现你没有预料到的重要错误时，TDD就变得很有意义。

- n00b · Answer 4

1

我认为这完全取决于所给定的时间范围。如果你有足够的时间，可以花费比通常需要的时间多近一倍的时间，那就去做吧。但在我看来，速度如今是最重要的因素之一（对于竞争激烈的公司而言）。

- n00b

这个“通常需要”是否包括编写非正式测试计划和流程的时间，以及当测试失败时重新进行修订所需的时间？还是说“通常需要”只是指编写代码而不进行任何测试所需的时间？ - S.Lott

这意味着你的版本中的第一个。 - n00b

2

我很惊讶的是，通常进行非正式测试和重构所需的时间似乎比进行TDD所需的时间少。但在实践中，我从未观察到这种情况。代码编写后，非正式测试似乎需要花费很长时间。事实上，我曾见过一些项目因无法通过这种非正式测试和重构流程而被取消。我猜你的非正式测试速度和准确性都非常快。这太神奇了。我想更多地了解您如何快速准确地完成非正式测试。您是否有博客可以发布您的经验？ - S.Lott

1

对不起，我的朋友们……我没有声称我是正确的。你们可能是对的。我肯定需要赶上你们拥有的30年开发经验:) 无论如何，感谢你们半路给予的建设性批评！ - n00b

@JaZz: 我对你回答中的“几乎是两倍时间”的部分很好奇。你能提供一些TDD比手动测试花费两倍时间的证据吗？也许你有很好的信息，能分享一下吗？ - S.Lott

显示剩余2条评论

- zanlok · Answer 5

一个使用良好的面向对象编程开发的项目天生适合测试，并且可以在开发风格后期获得测试驱动的重点。实际上，我会说当你在有限的预算下瀑布式开发新兴技术时，考虑所有TDD完全是可选的。

- David Ackerman · Answer 6

我认为TDD很值得，不管规模大小（即使只有一个类 - 因为先编写测试可以帮助您设计出更合理的设计）。

我觉得可能不必要的地方是当您在构建一个项目时不确定您想要什么，并且您不太可能关心可维护性时。我发现在工作中没有任何符合这种情况的项目，但我发现偶尔会开发个人项目，情况就是如此。在这些情况下，我通常正在学习新框架，从一开始就不知道自己在做什么，因此我的测试更有可能由于错误原因而随着时间而失败，从而降低其价值。

但是，我也承认不使用TDD会影响我的可维护性 - 一旦我知道自己在做什么，我会迅速退回到红/绿/重构。

- Liberty Lover · Answer 7

摘要

您已经有很多答案了。虽然您的问题已经几年了，但是请允许我加入：是的-进行TDD！测试您的代码！聪明地处理它。

契约式设计

TDD和BDD最好在Hoare逻辑前提条件和后置条件（以及其他形式的代码正确性布尔断言）的背景下理解。我曾经使用过的最好应用程序是EiffelStudio中的Eiffel。

Code-Fail-Correct模型还好，直到开始衡量开发人员和QA人员花费在纠正错误上的时间。

您也可能会在TDD和BDD方面犯大错。 TDD最终可能会生成大量的代码膨胀，其中您的测试代码比生产代码更大且更难维护。 BDD-实际上主要是DbC-也可能被误解、误用和管理不当，其自身的复杂性、膨胀和成本开销也同样存在。

需求

最深刻的需求是一种语言规范、编译器、IDE和测试系统，其中TDD + BDD（又名DbC）是内置的，并且所有正确的部分都放在正确的位置，而不是作为TDD + BDD伪装的螺栓式Frankenstein垃圾。

我觉得很有趣的是看程序员们试图将TDD和BDD的常见实现方式塞进那些根本没有设计契约概念的主流语言中，他们总是通过这种语言规范/编译器/IDE的视角来解释TDD + BDD，好像他们真正理解了这个东西。但事实上，他们从未真正看到这种做法是多么愚蠢和扭曲。

重返冷战

TDD + BDD (DbC)就像其他技术和主题一样会被扭曲。例如：不要试图使用Java作为理解面向对象理论的镜头。对于C++或其他基于C的语言也是如此。试图使用一种语言来学习OO就像认为了解你的计算器会让你理解微积分一样。

我所知道的唯一一个从TDD和BDD的理论理解出发构建语言规范、编译器、IDE和测试系统的语言是Eiffel和EiffelStudio。我已经使用它20年了。我已经走过这条路很多次了。看到你们在这些（对我来说）清晰明了如春天无云的话题上苦苦挣扎和扭曲，让我感到沮丧。