更好的单元测试指南

Question

吉米·博加德写了一篇文章：Getting value out of your unit tests，他给出了四条规则：

• 测试名称应从用户的角度描述的内容和原因
• 测试也是代码，给他们一些爱
• 不要选择一种固定模式/组织风格
• 一次设置，执行，验证每次测试

您认为这些指南是完整的吗？您的单元测试指南是什么？ 请避免使用特定的语言习语，尽量保持与语言无关的答案。

Answer 1

有一本名为xUnit Test Patterns的完整的850页书籍可以解决这个问题，因此不能轻易归结为一些硬性规则（尽管你提到的规则很好）。

一本更容易理解的书也涵盖了这个主题The Art of Unit Testing。

如果我可以添加规则，我发现大多数很重要，那么它们将是：

• 使用测试驱动开发。这是迄今为止进行良好单元测试的最有效途径。试图将单元测试改造为现有代码往往很难。
• 保持简单：理想情况下，单元测试应少于10行代码。如果它增长到超过20行代码，你应该认真考虑重构测试代码或你正在测试的API。
• 保持快速。单元测试套件意味着非常频繁地执行，因此旨在将整个套件保持在10秒以下。这很容易意味着将每个测试保持在10毫秒以下。

Answer 2

编写单元测试很简单，编写单元可测试代码很困难。

Answer 3

The Way of Testivus

• 如果您编写代码，请编写测试。
• 不要卡在单元测试教条上。
• 拥抱单位测试业力。
• 将代码和测试视为一个。
• 测试比单位更重要。
• 测试的最佳时间是代码是新鲜的。
• 测试不会浪费掉。
• 今天的不完美测试总有一天比完美测试好。
• 丑陋的测试比没有测试好。
• 有时，测试证明了手段的合理性。
• 只有傻瓜才能使用工具。
• 好的测试失败。

Answer 4

• 定期打破测试中的代码以查看单元测试的有效性

Answer 5

查看测试的代码覆盖率，并尝试使其合理完成（对于错误情况，我会使用一些自由裁量权来测试它们。）

Answer 6

有关编写单元测试的更多好主意，search stackoverflow.com。