Jimmy Bogard 写了一篇文章：“从你的单元测试中获得价值”，在文章中他给出了三条规则：
- “测试名称应该从使用者的角度来描述是什么以及为什么”；核心思想是一名开发者应该能够从测试名称理解测试行为是什么样的。
- “测试也是代码，爱他们吧”；仅在产品代码中做重构是不够的。易于理解的测试更易于维护，而且后来的人也更容易弄清楚。 “我憎恨、憎恨长而复杂的测试。如果一个测试的 setup 方法有 30 行，请将这些代码放在一个 creation 方法中。一个长测试会激怒开发者并让其头昏眼花。如果在产品代码中没有长方法，为什么会允许在我们的测试代码中有长方法？”
- “不要设定单一 fixture 的模式 / 组织风格”；通常情况下是一个类对应一个 test fixture，但有时候这样的标准并不适用。
Lior Friedman 补充：“规则#0——测试外部行为而不是内部结构。” 或者，测试一个类的期望行为而不是它的目前结构。
Ravichandran Jv 补充了他自己的规则：
- 尽可能做到每个测试一个断言。
- 如果在一个测试中有任何“if else”语句，将语句分支移到单独的测试方法中。
- 如果被测试的方法有 if else 分支，该方法应该被重构。
- 测试方法名称应该表明是某种测试。例如，TestMakeReservation 与 TestMakeNoReservation() 是不同的。
NUnit 的作者 Charlie Poole 再次说明：每测试一断言的说法为一个“逻辑断言”，他说：“有时，由于被测试的 api 缺乏表达能力，你需要写多个断言语句来获得期望的结果。在 NUnit 框架 api 的开发中，很多工作就是试图让一个断言做更多的工作。”
Bryan Cook 提出了他自己的列表：
- 实作：Fixture 命名保持一致
- 实作：模拟目标代码的命名空间
- 实作：Setup/TearDown 方法命名保持一致
- 考虑：分离测试与产品代码
- 实作：按功能给测试命名
- 考虑：在期望异常的命名中使用“Cannot”作为前缀
评论