unit-testing - 如何将单元测试改造成代码库？

Question

您是否有任何将单元测试改进到当前没有单元测试的代码库的策略？

Answer 1

阅读Feathers 的《有效使用遗留代码》。

Jimmy Bogard 有一个很好的关于 SOC 的博客系列。

Answer 2

在没有任何单元测试的情况下改造现有项目的最佳方法是在修复错误时进行。编写一个测试，该测试在包含错误的逻辑上失败，并提供重现错误的步骤。然后重构代码直到测试通过。现在您可以确信该错误已修复并且不会在周期的后期引入，并且您开始在项目中引入单元测试。

Answer 3

这是另一篇关于测试的好文章。特别是，它的一些相关引用：

这是一个糟糕的主意——决定你要花一整周的时间为你的项目构建一个测试套件。首先，您可能会在测试中感到沮丧和精疲力尽。其次，一开始你可能会写出糟糕的测试，所以即使你写了一堆测试，你也需要回去重写它们，你会发现它们有多慢、多脆弱或不可读。

我认为您最好在修复错误或添加新功能时一次构建测试 1...不要尝试构建缺少的测试用例，您应该为每个测试设定最终目标，而不仅仅是提高覆盖率.

Answer 4

戴尔获得投票支持。是的，将单元测试添加到有效的代码中没有任何好处。假设有两个未知的错误 X 和 Y。在某些时候，典型的现场使用揭示了 X。你修复它，添加一个单元测试，然后继续。现在假设 Y 在程序的整个生命周期中从未被发现。由于 Y 从未现身，就好像它从未存在过一样；没必要浪费资源。将其乘以成百上千的休眠错误，您就可以节省大量多余的维护工作。

Answer 5

如果您尝试将单元测试添加到旧的 perl 代码中，我强烈推荐

Perl 测试： Ian Langworth 和 chromatic 的开发者笔记本。

它在测试遗留和“不可测试”代码方面有一些非常好的技巧。

Answer 6

为什么要添加单元测试？你觉得代码有错误吗？你只是想做点什么吗？您是否即将开始一项新功能？

如果它是已经发布了很长一段时间的旧产品，那么我会同意其他产品，并且仅在发现错误或添加新功能时才添加测试。

如果它是仍在开发中且尚未发布或只是最近才发布的产品，那么我将首先查看代码。如果我看到一些不太正确的东西，那么我会为它添加一个测试。我可能会做一些测试来创建一些示例数据。创建样本数据似乎物超所值，而且它也很有用。

我认为即使您没有要测试的错误，编写测试也是有好处的——当您稍后添加新功能或修复错误时，您的测试确认您没有引入新错误。

Answer 7

我们是否可能处于恐慌之中并且在单元测试和性能测试之间感到困惑？是不是您的应用程序在少数用户的情况下运行良好，但在负载较重时开始抛出错误？如果是这样，单元测试不是答案。单元测试！=负载测试。

如果单元测试实际上是答案，那么改进单元测试是一个好主意，因为它有助于清理代码。只要准备好重构很多。使用 TDD 编写的代码看起来与没有使用 TDD 编写的代码有很大不同。就我而言，我有一个处理很多情况的方法 HandleDisposition()。如果我们用 TDD 编写代码，就不会存在这种方法。在改造单元测试时，我们重构了该函数，现在有了 XDisposition()、YDisposition()、ZDisposition() 等方法，这些方法更容易编写单元测试。