为现有代码编写测试

Question

假设有一个相对较大的程序(比如C#中的900 large )，所有的注释/文档都是完整的，组织良好，工作良好。整个代码库是由一个不再在公司工作的高级开发人员编写的。所有的代码都是可测试的，而且IoC在整个过程中都是使用的--除了一些奇怪的原因，他们没有编写任何单元测试。现在，您的公司希望对代码进行分支，并希望添加单元测试来检测更改何时破坏了核心功能。

• 添加测试是个好主意吗？
• 如果是这样的话，一个人会如何开始这样的事情呢？

编辑

好吧，所以我没有预料到答案能为相反的结论提供好的论据。无论如何，这个问题可能不在我的控制范围之内。我也读过“重复的问题”，普遍的共识是“编写测试是好的”...yeah，但在这种特殊情况下没有太大的帮助。

我不认为在这里只有我在考虑为遗留系统编写测试。我将保留关于花费多少时间和新测试捕获问题的次数(以及它们没有捕获问题的次数)的指标。我会回来更新这一年左右，从现在起，我的结果。

结论

因此，基本上不可能仅仅在现有代码中添加任何正统的单元测试。一旦代码运行，您显然无法对测试进行红灯/绿灯，通常不清楚哪些行为是重要的测试，不清楚从哪里开始，当然也不清楚什么时候完成。实际上，即使是问这个问题，从一开始就忽略了写作测试的要点。在大多数情况下，我发现使用TDD重写代码实际上比解密预期的函数和追溯添加单元测试要容易。当修复一个问题或添加一个新特性时，情况就不同了，我相信现在是添加单元测试的时候了(正如下面的一些人所指出的)。最终，大多数代码都会被重写，通常比您预期的要快--采用这种方法，我已经能够将测试覆盖率添加到现有代码库中惊人的大块中。

Answer 1

虽然测试是个好主意，但最初的程序员在构建应用程序时会构建测试，以获取代码应该如何工作的知识，以及可能会发生什么故障，然后将其转移给您。

在采用这种方法时，很有可能会编写最不可能中断的测试，并且忽略了在构建应用程序时会发现的大多数边缘情况。

问题是，大部分价值将来自那些“棘手”和不太明显的情况。没有这些测试，测试套件几乎失去了所有的有效性。此外，公司会对自己的应用有一种虚假的安全感，因为它不会得到更多的回归证明。

通常，处理这种类型的代码基的方法是编写新代码的测试和旧代码的重构测试，直到遗留代码库完全重构为止。

还有看见。

Answer 2

是的，增加测试绝对是个好主意。

你说它有很好的记录，这使你处于一个良好的地位。尝试使用该文档作为指南创建测试，重点关注系统的关键部分或经常更改的部分。

最初，与少量的测试相比，代码库的庞大规模可能会让人望而却步，但并没有大爆炸的方法，在某个地方开始比为什么才是最好的方法而烦恼更重要。

我会推荐迈克尔羽毛的书，有效地工作与遗产代码，作为一些好的，详细的建议。

Answer 3

并非所有单元测试都有相同的好处。单元测试的好处是当它失败时。失败的可能性越小，好处就越小。新的或最近修改的代码更有可能包含bug，而不是很少在生产中经过良好测试的更改代码。因此，对新代码或最近更改的代码进行单元测试更有可能更有益处。

并非所有单元测试都有相同的成本。今天你自己设计的单元测试琐碎代码要比其他人很久以前设计的复杂代码容易得多。此外，开发期间的测试通常会节省开发时间。在遗留代码上，成本节约不再可用。

在理想的世界中，您将有所有需要的时间来对遗留代码进行单元测试，但在现实世界中，在某种程度上，将单元测试添加到遗留代码中的成本将超过收益。诀窍是找出这一点。您的版本控制可以通过向您展示最近更改的代码和最频繁更改的代码来帮助您，并且您可以从将这些代码置于单元测试开始。此外，当您继续进行更改时，将这些更改和密切相关的代码置于单元测试之下。

按照这种方法，最终您将在最有利的领域有相当好的覆盖范围。如果你在恢复创收活动之前花了几个月的时间进行单元测试，那可能是一个理想的软件维护决策，但这是一个糟糕的商业决策。