我正在开发一个大型 Flask Web 应用程序。
一开始我选择不使用测试驱动开发，因为学习曲线和项目截止日期的原因。
因此，最近几周我有机会了解更多有关它的信息，并且对开始使用它感到非常兴奋。
但是，关于我从一开始就没有用 TDD 包装我的项目，现在开始使用它有什么缺点吗？
我不会重构我的整个应用程序，只会重构我将在不久的将来设计的新功能。
【问题讨论】：
标签： python unit-testing testing tdd
当然。这实际上是进行单元测试的好时机，因为您的项目已经开始了。
通常，在开始一个项目时，技术要求不是很可靠，并且需要进行大量的实践实验。在此期间，单元测试可能会产生大量时间开销。如果技术规范不是很可靠，那么更高级别的测试通常更有价值。这些可以包括通过公共接口（与客户端将使用的接口相同）发送测试请求，并对响应/数据/等进行广泛断言。这允许在更高级别的测试下更改服务的实现。
我能想到的一个稍后开始的问题是围绕单元测试的目标。对我来说，单元测试主要是学习如何编写可测试代码的工具，即耦合、抽象、封装、seams 等。如果您没有练习过编写此类代码，那么您就错过了学习的机会！
如果您没有测试工具设置，那么创建目录结构、测试层次结构、合并您的测试运行器、测试覆盖率/结果报告 (xml)、测试运行器集成都会产生开销。如果可以的话，像 travis 这样的托管服务将真正减少将其整合到您的开发流程中所涉及的工作量。
【讨论】：
“正确完成”TDD 始终是一种很好的做法 - 无论您是在什么时候开始使用它。
但为了避免出现代码库的一部分经过良好单元测试而其他部分未经过单元测试的情况：寻找不仅涵盖新功能的方法。换句话说：如果时间允许，不要只测试新功能将进入的文件/类的那些部分 - 而是尝试将整个单元放入“测试”中。
单元测试的核心方面是它们允许您在不破坏代码的情况下对代码库进行更改。单元测试使您能够以更高的速度前进。因此，请寻找方法来确保您可以“高速”处理大部分代码库。
【讨论】：
同意前面的回答。 是的，您可以在每个开发点开始使用 TDD。
当您尝试“红线”测试应该在开始出现时，您不会感到惊讶，因为它们显示出缺乏功能。
当您开始在大型系统上实施 TDD 时，您应该首先通过编写测试（或测试组）来检查某些功能的可用性。然后，如果它运行良好，则继续进行，直到测试开始显示代码潜力的极限。
要补充一点，如果您现在开始并决定在这一点上不仅涵盖新功能（还包括旧功能以及上面提到的），那么您更有可能将更多时间花在旧功能上。
在这种情况下，它不会被称为纯 TDD（只是说），因为一些测试将在编写代码后实施，但如果它适合项目，这也是一种选择（绝对值得）。而且现在测试某些东西很可能比在 beta 测试阶段更好。至少因为如果您发现旧功能出现问题，您会更容易找到解决方案。
所以后来你的测试变得如此困难，以至于解决问题。那需要更多的时间。如果人们在编写代码后很长时间才应用测试，那么就需要双重工作，因为您需要重新考虑代码的工作方式。这就是为什么在 TDD 中编写测试几乎与编写代码同时进行。即使在这一点上，您也可能更容易记住一开始的编码。
【讨论】：