一些单元测试的Guideline
Jimmy Bogard 曾经写过一篇文章： 《从单元测试中获益》，这这篇文章中给出了下面三条规则：
“测试名应该从用户的角度描述是什么和为什么” – 这样一来，程序员可以从名字就可以知道用户需要什么样的软件行为。
“测试也是代码，同样也需要我们更多的爱” – 真实运行在生产环境下的代码不仅仅只是我们需要去关心和花心思的代码。对于单元测试中的代码同样也需要易读易维护，以及可重用的特性。“我非常痛恨那些又长又复杂的测试代码，如果一个测试需要30行的单元测试代码，请把其放在一个方法中。一个长的测试步骤只会激怒程序员。如果你在正式的代码中都没有这么长的代码，那么为什么我们需要在测试代码中容忍这样的情形呢？”
“不要只用一种固定的模式或组织风格” – 有些时候，对于一些特殊的测试案例，标准的类设计模式，或一个固有的测试装置可能并不能有效的工作。
Lior Friedman 加上： “第0条 – 测试应该只测试单元其外部的行为，而不是内部的结构”。或者说，只测试对一个单元的期望，而不是这个单元的构成。
Ravichandran Jv 也加上了他的条例：
一个测试一个断言（如果可 ...
