我有一些中型Rails应用程序，我经常工作，其中只有一个有任何单元测试。但我已经看到了光明，我想要改变所有这些，除了......我没有时间进入并开始逐类编写测试或类似的东西。
如何在有限时间内在现有代码库上开始编写单元测试？例如，由于任何方法都必须是增量的，您如何订购单元测试？从肤浅的测试开始，然后继续进行更多的覆盖，或者只覆盖几个类......等等。
注意：我问这个问题考虑Rails，但我真的很感兴趣它适用于任何语言。
修改：注意，此问题与this other one不同。另一个人问这有多难，结果值得。我问的是如何添加单元测试。
答案 0 :(得分：10)
以下是我通常开始将单元测试添加到一个没有以这种方式开始的项目的方式：等待某人提交错误，然后编写一个单元测试来重现该错误。然后修复单元测试。这不仅开始构建单元测试，而且现在没有人会指责你对给定的bug进行回归。
答案 1 :(得分：5)
我的回答并非特定于Ruby on Rails。下次需要触摸代码库，修复错误或添加新功能时，请为您触摸的代码部分编写测试。如果您可以节省几分钟，请添加一些相关测试。如果您发现需要重构，请继续编写测试以支持这一点。随着时间的推移，你将建立测试覆盖范围，你会发现你总是对你需要的区域进行测试（因为那些是你正在编写的测试）。
答案 2 :(得分：5)
Working Effectively With Legacy Code by Michael C. Feathers
它有一套令人难以置信的完整技术，可以从没有单元测试覆盖率的现有代码库开始，逐步使其受到测试。如果我只推荐一本关于TDD的书，那就是这本书。
希望这有助于......祝您好运！
泰勒
答案 3 :(得分：2)
当我开始编写真正的单元测试（使用模拟等）时，我遇到的一个问题是我有返回并更改代码以支持模拟对象的注入，主要是通过接口的提取。我相信你很难在没有某种重构的现有系统上做到这一点。
答案 4 :(得分：0)
增加代码覆盖率是让新员工熟悉代码库的绝佳方式。
除了我认为你只需要找时间，没有神奇的解决方案！
答案 5 :(得分：0)
从长远来看，单元测试应该让用户更快地获得（工作！）功能。
如果没有完成，那就不值得花时间了。
答案 6 :(得分：0)
时间有限？面临最后期限？
忘记单元测试了！
牛仔编码4胜利！
Hack一起使用，直到现在为止并且客户没有起诉你的公司。
P.S。为了您自己的安全 - 不要忘记告知您的PM情况。
奇怪的是，投票雪崩还没有开始。也许它并不是那么糟糕，并且告诉不要编写单元测试并不是一个禁忌。
我处于类似情况（假设你的时间非常有限）。我做什么 - 我大部分时间都不考虑单元测试。但是对于某些情况 - 实际上更容易做TDD而不是继续黑客攻击（嗯......导管编带？：D）所有东西在一起（通常当可测试单元具有高复杂性或难以手动测试时），然后我只是转过头来和代码正常。在短期内 - 我将能够理解我在一个月前写的内容，这不会有太多麻烦。当项目进入维护阶段时会出现问题。但它仍然比告诉客户你在测试和got nothing new上工作要好得多。
当您需要在现有项目中启动单元测试时 - 从您自己的功能开始。创建必要的测试基础架构（如果时间允许 - 也可以进行持续集成）并且不要忘记向您的同事传授单元测试。
你（或PM）可以做的最糟糕的事情 - 强迫将单元测试编写给不知道如何操作的人。那只是在浪费时间。以身作则。逐渐。
毕竟它确实开始了！ ^ _ ^