显然，这两个清单很相似。不过，如果仔细看，您会发现 TestNG 的编码规则比 JUnit 4 更灵活。清单 1 里，在 JUnit 中我必须把 @BeforeClass 修饰的方法声明为 static，这又要求我把 fixture，即 finder 声明为 static。我还必须把 init() 声明为 public。看看清单 2，您会发现不同。这里不再需要那些规则了。我的 init() 方法既不是 static，也不是 public。
从初起，TestNG 的灵活性是其主要优势之一，但这并非它惟一的卖点。TestNG 还提供了 JUnit 4 所不具备的其他一些特性。
依赖性测试
JUnit 框架想达到的一个目标是测试隔离。它的缺点是：人们很难确定测试用例执行的顺序，而这对于任何类型的依赖性测试都非常重要。开发者们使用了多种技术来解决这个问题，例如，按字母顺序指定测试用例，或是更多地依靠 fixture 来适当地解决问题。
如果测试成功，这些解决方法都没什么问题。但是，如果测试不成功，会产生一个很麻烦的后果：所有 后续的依赖测试也会失败。在某些情况下，这会使大型测试套件报告出许多不必要的错误。例如，假设有一个测试套件测试一个需要登录的 Web 应用程序。您可以创建一个有依赖关系的方法，通过登录到这个应用程序来创建整个测试套件，从而避免 JUnit 的隔离机制。这种解决方法不错，但是如果登录失败，即使登录该应用程序后的其他功能都正常工作，整个测试套件依然会全部失败！
跳过，而不是标为失败
与 JUnit 不同，TestNG 利用 Test 注释的 dependsOnMethods 属性来应对测试的依赖性问题。有了这个便利的特性，可以轻松指定依赖方法。例如，前面所说的登录将在某个方法之前 运行。此外，如果依赖方法失败，它将被跳过，而不是标记为失败。
清单 3. 使用 TestNG 进行依赖性测试
import net.sourceforge.jwebunit.WebTester;
public class AccountHistoryTest {
private WebTester tester;
@BeforeClass
protected void init() throws Exception {
this.tester = new WebTester();
this.tester.getTestContext().
setBaseUrl("http://div.acme.com:8185/ceg/");
}
@Test
public void verifyLogIn() {
this.tester.beginAt("/");
this.tester.setFormElement("username"， "admin");
this.tester.setFormElement("password"， "admin");
this.tester.submit();
this.tester.assertTextPresent("Logged in as admin");
}
@Test (dependsOnMethods = {"verifyLogIn"})
public void verifyAccountInfo() {
this.tester.clickLinkWithText("History"， 0);
this.tester.assertTextPresent("GTG Data Feed");
}
}
在清单 3 中定义了两个测试：一个验证登录，另一个验证账户信息。请注意，通过使用 Test 注释的 dependsOnMethods = {"verifyLogIn"} 子句，verifyAccountInfo 测试指定了它依赖 verifyLogIn() 方法。
通过 TestNG 的 Eclipse 插件（例如）运行该测试时，如果 verifyLogIn 测试失败，TestNG 将直接跳过 verifyAccountInfo 测试，请参见下图 ：
图 在 TestNG 中跳过的测试
对于大型测试套件，TestNG 这种不标记为失败，而只是跳过的处理方法可以减轻很多压力。您的团队可以集中精力查找为什么百分之五十的测试套件被跳过，而不是去找百分之五十的测试套件失败的原因！更有利的是，TestNG 采取了只重新运行失败测试的机制，这使它的依赖性测试设置更为完善。
失败和重运行
在大型测试套件中，这种重新运行失败测试的能力显得尤为方便。这是 TestNG 独有的一个特性。在 JUnit 4 中，如果测试套件包括 1000 项测试，其中 3 项失败，很可能会迫使您重新运行整个测试套件（修改错误以后）。不用说，这样的工作可能会耗费几个小时。
一旦 TestNG 中出现失败，它会创建一个 XML 配置文件，对失败的测试加以说明。如果利用这个文件执行 TestNG 运行程序，TestNG 只 运行失败的测试。所以，在前面的例子里，您只需重新运行那三个失败的测试，而不是整个测试套件。
实际上，您可以通过清单 2 中的 Web 测试的例子自己看到这点。verifyLogIn() 方法失败时，TestNG 自动创建一个 testng-failed.xml 文件。该文件将成为如清单 4 所示的替代性测试套件：
清单 4. 失败测试的 XML 文件
<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">
<suite thread-count="5" verbose="1" name="Failed suite [HistoryTesting]"
parallel="false" annotations="JDK5">
<test name="test.com.acme.ceg.AccountHistoryTest(failed)" junit="false">
<classes>
<class name="test.com.acme.ceg.AccountHistoryTest">
<methods>
<include name="verifyLogIn"/>
</methods>
</class>
</classes>
</test>
</suite>
运行小的测试套件时，这个特性似乎没什么大不了。但是如果您的测试套件规模较大，您很快会体会到它的好处。
