xUnit测试脚本设计方法：原则

原则1：测试优先

说到写软件之前先为软件写自动化测试的概念时，有人会露出疑惑的表情。他们会问“怎样可能为不存在的软件写测试呢？”。

赞同进行TDD方主要有以下两个论点：

(1) 单元测试节省了大量调试精力，这种精力通常会完全抵消自动化测试的成本。

(2) 写代码之前写测试可以尽早考虑到设计代码的易测性。“不能测试的代码绝对是糟糕的代码。”

结论：在开发代码之前先为代码写测试。

原则2：前门优先

对象有几种类型的接口。有客户所能使用的“公有”接口，也有只有内部才能使用的“私有”接口。

通过内部接口来建立夹具或验证结果（后门操作），会导致测试脚本与开发代码过度耦合，从而导致测试“脆弱”。

结论：优先通过公有接口测试对象（前门操作）。

原则3：单一条件测试

利用一个测试用例的结束状态作为下一个测试用例的起始状态，这种方法很有诱惑力，它让测试更有效率。但并不推荐这种方法。

（1）因为当一种断言失败时，剩下的测试就不能执行。因此，很难定位缺陷。

（2）测试脚本的可读性较差，查看用例覆盖时不得不去读所有的脚本内容。

（3）测试夹具是从编程上建立的而不是由人建立。程序可以非常迅速地建立夹具。所以“每个脚本测试单个条件用例”这种单一思想是可能的。

结论：让每个脚本测试单个条件用例。

原则4：从外到内or从内到外?

(1)从内到外开发，意思是从最里面的组件开始，继续向用户界面开发，在以前构造的组件的基础之上构建。

（2）由外向内设计软件，意思就是应该先考虑整个系统的黑盒客户测试(也称为故事测试)，然后考虑软件各部分的单元测试。

如果下级不存在，可以使用测试替身代表它们。一旦建立下级以后，就可以从许多测试中删除测试替身。

结论：优先采用由外到内的开发测试模式，这些测试激励我们在开始像软件开发人员那样思考之前先“像客户一样思考”。首先关注的应该是提供给软件用户的接口。测试捕获这些接口的用法，帮助枚举需要支持的各种场景。

原则5：状态验证or行为验证?

“状态主义者”观点表示将SUT放入特定状态，运行它，验证SUT在测试结尾是否处于预期的状态，这样就足够了。

而“行动主义者”的观点，不仅应该指定SUT的起始和终止状态，而且应该验证SUT进行的调用和操作。

（1）优点：行为验证有利于单独测试软件的各个单元，虽然要以更复杂的测试脚本重构作为代价。

（2）缺点：必须使用特殊方法来捕捉它们之外(因为它们不直接返回到客户或测试)，实现复杂和脆弱。

结论：主要使用状态验证，但需要获得好的代码覆盖时，会采取行为验证。