我们是否有任何策略可以将单元测试改装到当前没有单元测试的代码库上？

解决方案

回答

阅读Feathers的《有效处理旧版代码》。

Jimmy Bogard在SOC上有一个不错的博客系列。

回答

这是关于测试的另一篇很棒的文章。特别是其中一些相关的引用：

Here’s a terrible idea - decide you are going to spend a whole week building a test suite for your project. First of all, you’ll likely just get frustrated and burn out on testing. Secondly, you’ll probably write bad tests at first, so even if you get a bunch of tests written, you’re going to need to go back and rewrite them one you figure out how slow, brittle, or unreadable they are.

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

回答

无需任何单元测试即可改造现有项目的最佳方法是在修复错误时进行。编写一个对包含错误的逻辑失败的测试，并带有重现该错误的步骤。然后重构代码，直到测试通过。现在，我们可以放心，该错误已修复，并且不会在本周期的后续版本中引入，并且我们开始在项目中引入单元测试。

回答

戴尔被投票。是的，向有效的代码添加单元测试没有任何好处。可以说存在两个未知的错误X和Y。在某些时候，典型的现场使用会揭示X。我们对其进行了修复，添加了单元测试，然后继续进行。现在，假设在程序的整个生命周期中从未发现过Y。由于Y从不透露自己，就好像它不存在一样。无需浪费资源。将其乘以成百上千个潜在的错误，可以为我们节省大量不必要的维护工作。

回答

如果我们尝试将单元测试添加到旧的Perl代码中，强烈建议

Perl测试：Ian Langworth和chrom编写的开发人员笔记本。

它在测试遗留代码和" unestable"代码方面有一些非常好的技巧。

回答

为什么要添加单元测试？我们觉得代码中有错误吗？你只想做点什么吗？我们即将着手一项新功能吗？

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

如果它是仍在开发中且尚未发布或者仅是最近发布的产品，那么我将首先检查代码。如果发现不正确的地方，则需要对其进行测试。我可能会进行一些测试以创建一些样本数据。创建样本数据似乎可以为我们带来很大的收益，它也很有用。

我认为编写测试是有好处的，即使我们在添加新功能或者稍后修复错误时没有要测试的错误时，测试也证实我们没有引入新的错误。

回答

我们是否可能会感到恐慌并且在单元测试和性能测试之间感到困惑？是应用程序可以在很少的用户中正常运行，但是在负载较重时开始引发错误吗？如果是这样，单元测试不是答案。单元测试！=负载测试。

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