单元测试稳定的生产应用

Question

在开发社区中，单元测试是必须具备的，这似乎是一个绝对真理，你应该不惜一切代价添加它（我知道它不是 100% 那样的）。 让我在这里扮演魔鬼的拥护者。

管理层希望引入单元测试，以期最大限度地减少每个开发周期中的回归开发错误。

这是一个 MVC Web 应用程序，具有良好的解耦水平，但具有大量不易测试的 .js 代码、存储过程等。很多时候，由于错误的实现或合并错误而发生回归错误。

所以我不是在问如何将单元测试添加到现有代码中，底部链接中有很多回答。 我最初的计划是构建具有许多场景的集成测试，这将涵盖“整个”应用程序。它似乎比 5000 多个单元测试更有价值。 然后我们可以尝试添加单元测试，如果确实如此，我们可以看到它的好处。

此外，单元测试的一些好处对我来说似乎很模糊，它允许您在不破坏应用程序的情况下替换框架，它允许您在不破坏应用程序的情况下重构代码。

现在，我问：
它是否有效地减少了回归错误？

您能否编写单元测试而无需大量重写应用程序？

你能保证重构代码不会产生代价高昂的新错误吗？ （我知道这不是一个有效的问题）您如何向业务解释您破坏了应用程序重构？

代码历史呢？有时，对于审计而言，了解为什么引入了某些代码而重构会失去该价值是非常重要的，如果幸运的话，您只会发现它在源代码控制中浏览了很长时间。

我知道你读过这篇文章，而且我是那些不会改变意见的心胸狭窄的人之一，我保证我不会！

归根结底，我们需要的是稳定性，而不是避免少数重新打开的缺陷。我想找到最有效的开始途径。

最后但并非最不重要的是，我确实阅读了其他精彩的主题。

Can unit testing be successfully added into an existing production project? If so, how and is it worth it?

请分享你的想法。

谢谢

Answer 1

我认为涵盖应用程序大片区域的集成级别或验收级别测试可能是一个很好的起点。它可能比单元测试更容易编写。

关于您的问题：

[单元测试] 能否有效地减少回归错误？

是的，如果您添加了正确类型的测试。每当我在代码中遇到错误时，我都会编写一个单元测试，利用该错误导致测试失败。修复错误后，测试通过。一旦该测试或一组测试在您的测试套件中，您永远不应该重新引入错误，因为这会导致测试失败。

但是，这要求 1) 您编写利用该错误的测试，2) 您定期运行测试以检测回归。 3) 只有通过所有测试的软件才会发布。

您能否编写单元测试而无需大量重写应用程序？

有可能，但不太可能。未经任何测试就已经投入生产的应用程序可能在设计时并未考虑到可测试性。因此，代码很可能必须重构，也许是为了正确测试它。

你能保证重构代码不会产生代价高昂的新错误吗？ （我知道这不是一个有效的问题）

不，你不能保证。特别是如果您需要在拥有良好的测试覆盖率以充当安全网之前大量重构代码。但是，这种情况应该很少发生，尤其是如果您还已经编写了集成测试。

您如何向业务部门解释您破坏了应用重构？

在进行重大软件重构之前，我希望您与您的利益相关者一起制定出重构计划。他们应该充分意识到短期内的风险和潜在的停机时间，以便在长期内提高可靠性和加快开发速度在项目获得批准之前！

代码历史呢？有时，对于审计而言，了解为什么引入了某些代码而重构会失去该价值是非常重要的，如果幸运的话，您只会发现它在源代码控制中浏览了很长时间。

嗯，正如你所说，你有源代码控制来显示历史作为最后的手段。但是，如果问题如此重要，您可能还应该为它编写测试，就好像它是我之前描述的错误一样。这样，如果您的重构重新引入了该问题，您将获得失败的测试。

重构遗留应用程序以编写单元测试（然后编写这些单元测试）是一项重大任务，不应轻易完成。

我曾经在我的公司完全重构/重新设计了一个遗留的关键任务 400k+ LOC 应用程序。花了很多年几乎100%的努力。当我“完成”并完成了最关键的 20% 的代码并将架构重新设计到可理解和可维护的水平时，行业格局已经发生了变化，应用程序不再重要。幸运的是，在项目过程中，我发布了大约 100 个版本，因此用户可以在项目终止之前利用改进的稳定性和新功能。

我想我的意思是，在开始这条道路之前，请确保付出努力是值得的。