【发布时间】：2010-06-29 20:40:15
【问题描述】：
重复极短的开发周期如何帮助您消除软件中的错误？如果正确实施，TDD 最能有效地捕捉哪些错误？为什么？
提前致谢！
【问题讨论】：
【发布时间】：2010-06-29 20:40:15
【问题描述】：
TDD 迫使您从“消费”您将要编写的代码的角度进行思考。这种观点有助于将您（开发人员）置于需要考虑如何构建 API 以及如何验证实现要求的位置。
TDD 有助于识别以下领域的缺陷：
- 要求。是否清楚代码需要做什么。是否可以验证代码的不变量或最终效果。需求中是否定义了成功标准，或者是否含糊不清或不存在。
- 易于使用。您能否有效地使用您计划编写的代码来实现最终用户所需的各种功能，或者将来集成的其他代码。
- 可测试性。 代码是否可根据设计中的可访问数据或对象进行验证。是否可以确认事情会按应有的方式运行。
- 边缘情况。通过预先确定边缘情况的存在，通常更容易识别和响应边缘情况。当游戏后期出现边缘案例时，人们倾向于尝试“强制”现有设计以适应它们，而不是重新考虑设计。
- 异常处理。当您开始编写测试用例时，您开始意识到您可能希望能够响应错误或异常情况的区域。这有助于规划您的异常处理策略、要抛出的异常类型、要包含的信息等。
TDD 还有助于提高测试的覆盖率，因为它将测试带到了前台，而不是使其成为“事后”活动。当测试最后进行时，由于时间和预算限制，或者由于开发人员的热情和动力自然下降，它最容易被忽略或忽视。
【讨论】：
设计“错误”：如果您通常进行 TDD，那么您自然会得到可测试的设计。反过来，这倾向于减少耦合等 - 导致代码库更容易使用。
另外，我发现 TDD 可以在某些情况下更容易考虑极端情况 - 但设计优势更重要，IMO。
【讨论】：
-
我明白了。它会帮助清除任何特定的错误吗？例如算术、逻辑、语法。
-
@user354822：语法错误通常会被编译器捕获……但如果您进行了适当的测试，则可以检测到各种错误。诚然，并发缺陷通常更难发现。
对我来说，空值或零值参数的情况是 TDD 最容易发现的错误。在这种情况下，我倾向于先编写我的测试，作为一种清除 API 的方式，而不考虑值：“哦，只是在里面扔一个空值；我们将在下一个测试中输入一个真正的值。”所以我的方法最初是为了处理特定的边缘情况而编写的，并在整个红绿重构过程中重复运行该测试（以及所有其他测试）以保持该边缘情况正常工作。在使用 TDD 之前，我会经常忘记 null 或零参数。现在，在没有真正尝试的情况下，它们被作为我应用 TDD 方式的自然结果来处理。
【讨论】：
-
您是否发现自己在使用
Null Object模式？ -
@Gutzofter：是的，我愿意；这是我的最爱之一。