在项目中途开始TDD，良好的做法？

Question

我正在开发一个大型Flask Web应用程序。

回到开头，我选择不使用测试驱动开发，学习曲线与项目截止日期的原因。

因此，在过去几周，我有机会了解更多信息，而且我很乐意开始使用它。

然而，关于我从一开始就没有用TDD包装我的项目，现在有没有开始使用它的缺点？

我不会重构我的整个应用程序，只会修改我将在不久的将来设计的新功能。

Answer 1

绝对。这实际上是进入单元测试的好时机，因为您的项目已经启动。

通常，在开始项目时，技术要求并不是非常可靠，并且在实施方面有很多实验经验。在此期间，单元测试可能会产生大量的时间开销。如果技术规格不是很高，那么更高级别的测试往往更有价值。这些可以包括通过公共接口（客户端将使用的同一个）发送测试请求，并在响应/数据/等上广泛断言。这允许服务的实现在更高级别的测试下进行更改。

我稍后可以考虑的一个问题是单元测试的目标。对我来说，单元测试主要是学习如何编写可测试代码的工具，即耦合，抽象，封装，seams等。如果你没有练习编写这种代码，那么学习的机会就是错过！

如果您没有设置测试工具，则会产生创建目录结构，测试层次结构，合并测试运行器，测试覆盖率/结果报告（xml），测试运行器集成的开销。如果你能够，像travis这样的托管服务将真正减少将其纳入你的开发过程所需的工作量。

Answer 2

TDD“做得对”总是很好的做法 - 无论你何时开始使用它。

但是为了避免陷入这样一种情况，即代码库的一部分经过了良好的单元测试，而其他部分则没有：寻找不仅涵盖新功能的方法。换句话说：如果时间允许，不仅要测试新功能将进入的文件/类的那些部分 - 而是尝试将整个单元转换为“测试”。

单元测试的核心方面是它们允许您在不破坏任何内容的情况下对代码库进行更改。单元测试使您能够以更高的速度运行。因此，寻找确保您可以为大多数代码库“高速”运行的方法。

Answer 3

同意之前的回答。 是，您可以在每个开发阶段开始使用TDD。

当您尝试＆＃39; 红线＆＃39;那些应该在开始时的测试，你会发现它们缺乏功能并不奇怪。

当您在大系统上实施TDD 并且已经有大量代码时，您应该首先检查一些功能可用性，同时编写测试（或测试组）。然后，如果它运行良好，则继续进行，直到测试开始显示代码的潜力限制。

如果您现在开始并且决定不仅涵盖新功能（但旧功能以及上面提到的功能），那么您将更有可能将更多时间用于旧功能。

在这种情况下，它不会被称为纯TDD（只是说），因为一些测试将在代码编写完成后实现，但如果它适用于项目，那么它也是选项（绝对值得）。而且现在测试某些东西比在beta测试阶段更有可能更好。至少是因为如果您发现旧功能出现问题，将更容易遇到解决方案。

所以稍后你会更加努力地尝试解决问题。那需要更多的时间。如果人们在代码编写完成后长时间应用测试，则需要重新考虑代码的工作方式。这就是TDD编写测试的原因几乎与编写代码一样。即使在这一点上，你可能更容易记住你在开始时编写的内容。