xUnit测试脚本设计方法:组织

1.按照开发代码结构组织测试脚本。
参照开发代码的结构，对应地组织测试脚本结构，是一种比较简单直观的组织方式。
优点：简单直观，与开发代码可以做到很好的对应。
缺点：需要各个接口集成的测试用例组织困难，每个测试方法可能需要创建不同的夹具。
2. 按照系统特征（Feature）组织测试脚本。
有一种想法是将验证SUT特征的所有测试方法(这里“特征”定义为共同实现SUT某种功能的一个或多个方法)放置到单个测试用例类。

优点：很容易理解该特征的所有测试用例。
缺点：它可能会导致每个测试用例类中需要不同的夹具建立码。
3.按照夹具(Fixture)组织测试脚本。
另一种观点是，将所有需要相同测试夹具(相同前置条件)的测试方法分组为每个夹具一个测试用例类。

优点：有利于将测试夹具建立码放置到setup方法。
缺点：每种功能特征的测试用例可能会被迫分散到不同的测试类。

4.测试代码命名约定
给测试用例类和测试方法起的名称至关重要，它能够让测试易于被发现和理解。不管使用哪种测试脚本组织方案，都要结合测试程序包的名称、测试用例类的名称及测试方法的名称来传达信息。目前我们的命名约定规则可参考http://www.51testing.com/index.php?uid-23978-action-viewspace-itemid-216391
类命名方式实例：test测试对象_测试条件_预期结果

例子1：

例子2：ThroughtWorks一位同学更大胆，中西结合，英语不好的同学的福音

我的看法：

没有可以遵循的单个"最佳实践"，最佳实践就是最适合于特定环境的实践。
a.当为有状态的对象写测试脚本，并且需要在对象的所有状态下测试每个方法时，通常使用每个夹具一个测试用例类。
b.当重点是需要对客户认识的特征实现功能覆盖时，使用每种特征一个测试用例类就比较合适。
c.如果是追求代码测试覆盖率，并不太关注各个代码模块的交互或者交互比较简单时，可以按照开发代码结构组织测试脚本。