关于不可知的语言：如何将单元测试改编为代码库？

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

---

阅读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，因为您正在修复错误或添加新功能...不要尝试构建丢失的测试用例，您应该为每个测试设定最终目标，而不仅仅是提高覆盖率。

---

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

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

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

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

---

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

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

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

---

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

---

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

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

---