来自Google的单元测试技巧

作者 Kurt Christensen 译者 乔梁 发布于 2007年4月27日

领域

过程 & 实践,

语言 & 开发

主题

JUnit ,

Google ,

单元测试 ,

测试驱动开发 ,

敏捷 ,

测试

分享到

在Google的测试Blog里，QA工程师们与大家分享了他们的单元测试心得。这一系列被称为“厕所墙上的测试”。

我们把从依赖注入到代码覆盖所有关于测试的心得体会都写下来，然后定期粘贴在Google所有的卫生间里，全球大约有500多个……。我们决定把这个“秘密武器”与大家分享，传递我们对测试的激情，为大家提供一个有趣而又简单的方法，以在你和你的公司里推广这些重要的技术与技巧。

这是个古怪的名字，但内容非常严谨。最新的内容“利用Red Bar状态重构你的测试用例”解决了一个常见的问题。即一旦单元测试套件变得庞大，如何在不破坏测试的前提下进行测试代码的重构呢？

如果你故意使代码不能通过测试，这个未通过的测试就会告诉你，你写的断言还在起作用。例如，如果你在CombineHarvesterTest中重构了你的方法，你就会改变CombineHarvester，让它返回错误的结果。

检查发现，这个测试失败的原因是你希望这个断言不能通过。这时，你就可以小心地重构这个不能通过的测试用例。只要它一通过，你就会知道这个测试用例不对了——取消它! 当你做完测试的重构以后，一定要记得修改你的源代码，使它可以通过你已经重构的测试用例。

• 利用Red Bar状态重构你的测试用例（HTML / PDF）
• 利用码桩加速你的单元测试（HTML / PDF）
• JavaScript: 在你的JsUnit测试用例中模拟时间（HTML / PDF）
• 用其承担的责任命名你的测试用例（HTML / PDF）
• 在Python中，使用更好的码桩（HTML / PDF）

译者 乔梁 有十多年软件开发及项目管理经验，专注于提高软件企业提高交付能力。现任百度项目管理部高级架构师。