事后你有没有在遗留代码中添加单元测试?代码有多复杂,存根和模拟所有内容有多困难?最终结果值得吗?
8 回答
我发现最好的方法是逐步添加单元测试,而不是直接说我们现在将对应用程序进行单元测试。
因此,如果您要接触代码,进行错误修复或重构,请先编写单元测试。对于错误,单元测试将有助于证明问题出在哪里,因为您可以复制它。
如果重构,你会想写单元测试,但是你可能会发现测试是不可能写的,所以你可能需要找一个高层,调用要重构的函数,然后对那部分进行单元测试。然后,当你重构攻击性功能时,编写测试以确保它按应有的方式运行。
没有简单的方法可以做到这一点。
这个问题可能有助于提供更多建议。 您如何将单元测试引入大型的遗留 (C/C++) 代码库?
Michael Feathers 的书“有效地使用遗留代码”是一整本书,涵盖了这个主题。Michael 指出,为遗留代码引入测试通常太难了,因为它的结构不是可测试的。我从书中得到最多的是一些名为“Sprout 函数”和“Sprout 类”的模式。Sprout 函数是一个封装了您需要在代码中进行的更改的函数。然后,您只需对这些功能进行单元测试。除了新功能包含在一个类中之外,新芽类是相同的想法。
是的,而且通常很痛苦。我经常最终不得不编写集成测试。
《单元测试的艺术》一书对此有一些很好的建议。它还推荐了《有效地使用遗留代码》一书;我还没有读过后者,但它在我的堆栈中。
编辑:但是,是的,即使是最小的代码覆盖率也是值得的。它给了我信心和重构代码的安全网。
编辑:我确实读过有效地使用旧代码,它非常好。
还要看看遗留代码单元测试领域的新方法 - Asis 项目,它受到ApprovalTests项目的启发并分享了它的关键概念。
正如本文中提到的 ApprovalTests 方法:
通常,您有一个巨大的遗留代码项目,根本没有测试,但您必须更改代码以实现新功能或重构。遗留代码的有趣之处在于——它有效!它可以工作多年,不管它是如何写的。这是该代码的一个非常大的优势。通过批准,只需一项测试,您就可以获得所有可能的输出(HTML、XML、JSON、SQL 或任何可能的输出)并批准,因为您知道 - 它有效!在完成这样的测试并批准结果后,重构确实更安全,因为现在您“锁定”了所有现有行为。
Asis 工具正是通过自动创建和运行特性测试来维护遗留代码。
欲了解更多信息,请查看
- 项目的 github repo 中的详细README
- 关于黑客新闻的讨论
- reddit.com/r/php上的讨论
- reddit.com/r/programming上的讨论
如果您计划重构遗留代码,那么创建这些单元测试是必须的。不要担心模拟或存根——担心测试系统的输入和输出,这样您的更改或重构工作就不会破坏当前的功能。
我不会对你撒谎,将单元测试改造成遗留代码是很困难的——但这是值得的。
特征测试是单元测试的一种替代方法,也在有效处理遗留代码中介绍。通过这样的测试,我得到了有趣的结果。它们比单元测试更容易设置,因为您从点测试而不是可以测试(称为接缝)。缺点是当测试失败时,您对问题位置的提示较少,因为被测区域可能比单元测试大得多。日志记录在这里有所帮助。
诸如 xUnit 系列的单元测试框架可用于编写特性测试。
在这样的测试中,在事实之后编写,断言验证代码的当前行为。与单元测试不同,它们并不能证明代码是正确的,它们只是确定(表征)代码的当前行为。
该过程与 TDD 类似:
- 为部分代码编写测试
- 执行它 - 失败
- 从观察到的代码行为修复测试
- 执行它 - 通过
- 重复
如果您修改代码的外部行为,测试将失败。代码的外部行为 ? 听起来很熟悉 ?是的,我们来了。现在您可以重构代码。
显然,风险取决于特性测试的覆盖范围。
查看免费的开源单元测试实用程序库ApprovalTests。如果您是 .NET 开发人员,那么创建者 Llewellyn Falco 制作了一系列视频,展示了他如何使用 ApprovalTests 来改进新代码和旧代码的单元测试。
我前段时间在 XPDays http://xpdays.com.ua/archive/xp-days-ukraine-2012/materials/legacy-code/上谈到了旧代码中的反向测试金字塔的想法
本演示文稿应该回答为什么在处理遗留代码时有时从集成/功能甚至高级验收测试开始如此重要的问题。然后慢慢地,一步一步地引入单元测试。没有代码示例 - 抱歉,但您可以在 Michaels Feathers 的书“有效地使用旧代码”中找到其中的一堆。
您也可以查看 Legacy Code Retreat http://www.jbrains.ca/legacy-code-retreat并查找您所在地区的会议。