是否有TDD可提供高ROI的区域，而其他ROI如此低以至于不值得效仿的区域？[关闭]

测试驱动的开发。我知道了，喜欢它。

但是编写测试确实需要开销。因此，应该在整个代码库中普遍使用TDD，还是在TDD提供较高ROI的区域以及其他ROI如此低以至于不值得关注的区域。

我想避免在代码可能在结构上发生很大变化的地方使用TDD。即，对一个方法的签名进行很少的测试是很不错的，但这种方法的签名很少更改，但是内部重构的频率更高，但是每次当高度易变的接口发生巨大变化时，都必须修复测试。

我最近正在使用的应用程序是基于Gui-> Presenter-> BusinessLogic->基于数据访问层的体系结构构建的数据驱动的webapp。我的数据访问层经过了无人问津的测试。业务逻辑层已经过很好的测试。演示者仅在更稳定的区域中进行测试，并且每小时更改一次的GUI几乎没有测试。

我建议在合理且实用的地方编写一个完整的测试套件。在不太实际的领域，编写健全性检查。

以我的经验，一整套测试用例的开销在大多数情况下当然是值得的，但实际上，代码覆盖范围的收益递减。在某个时候，编写更多的测试只是为了增加代码覆盖率是没有意义的。

例如，根据您的语言/技术，测试UI可能不切实际甚至不可行。许多测试可能取决于用户看到的内容，并且无法实现自动化。您将如何测试生成验证码的方法产生的图像可以被人类读取？

如果一整套测试将花费您三天的时间来编写，那么在该组件中引入错误的可能性非常低，并且该函数本身只需要半个小时的编写时间，您可能应该考虑一下关于那个时间是否值得。也许只是为该功能编写基本的健全性检查会提供价值？

我的一般建议是，您应该完全测试组件，以便可以相对轻松地编写测试。但是，如果这是一个很难测试的区域，请在沙子上画一条线并编写测试，以在更高级别上测试该区域，而不是对其进行全面测试。

在前面的验证码示例中，也许编写了返回正确大小和格式的图像的测试，并且没有抛出异常。这样可以为您提供一定程度的保证，而又不会太高。

对我来说，TDD不是开销。这就是我编写代码的方式。为什么您说笔试是“开销”？这只是过程的一部分。我的观点是调试是开销，这是我开始TDD-ing时基本上停止执行的活动。在TDD之前，调试是我的软件编写过程不可或缺的一部分。

我认为放弃调试以进行测试编写是很不错的选择。

在MVC应用程序中测试视图时，TDD确实很难胜任。

由于您正在测试一个返回胖html字符串的函数，因此您被困在进行html解析只是为了看看是否能解决问题。而且，它可能成为可维护性的噩梦。有一天，您将一个复选框移动到kaboom上，则测试已失败。

我在很多测试中都喜欢TDD，但它并不是程序员的唯一工具。