企业级Java开发者必须实现更宽、更深的测试覆盖率，除了单元测试之外，还需要实现功能测试、集成测试和系统验收测试。本书介绍了突破性的Java测试技术和TestNG,后者是一个强大的开放源代码Java测试平台。
C?dric Beust是TestNG的创始人，他和一流的Java开发者Hani Suleiman，向我们展示了一些强大的、灵活的测试模式 ，这些测试模式基本上可以适用于任何测试工具、框架或语言。他们展示了如何利用关键的Java平台改进来促进有效的测试，如依赖注入和模拟对象。还全面地介绍了TestNG，展示了它如何克服以前框架的一些局限以及如何利用新的技术，从而使得测试复杂的软件系统变得更容易。
本书讲求实用主义并关注结果，将帮助Java开发者为今天的关键任务环境创建更健壮的代码。
本书主要内容包括：
■ 展示了与测试有关的折衷考虑，这样您就能在测试什么和怎么测试方面做出更好的决定。
■ 介绍了TestNG，说明了它的目标和功能，并展示了如何在真实的环境中应用这些功能。
■ 展示了如何集成TestNG和已有的代码、开发框架以及软件库。
■ 展示了如何测试关键代码的特征，如封装、共享状态、范围和线程安全。
■ 展示了如何测试应用程序元素，包括Java EE APIs、数据库、Web页面和XML文件。
■ 展示了高级技术：测试部分失败、工厂、依赖关系测试、远程调用、基于集群的测试服务器群等。
■ 介绍了在Eclipse和IDE中安装TestNG插件。
■ 包含了大量的代码示例。
无论您使用TestNG、JUnit或其他测试框架，本书提供的测试设计模式都会告诉您如何改进您的测试，对如何让代码和设计变得更可测试提供具体的建议。
无
我们都在进行软件开发：编写代码，然后部署。当部署了代码之后，客户会表现高兴或不高兴。令人沮丧的是，他们经常表现得不高兴。
在过去的几十年里，人们为了减少这种不高兴编写了许多东西。我们有无数种语言、方法学、工具、管理技术和老式秘方，来帮助处理这个问题。
其中有些方法很有效。最近，人们将关注的重点重新放到了测试上，据说测试将给开发者和用户带来欢乐。
人们写了很多东西来赞美测试的优点。它可以让您的代码更好、更快、更轻。它可以为编码这样的乏味工作带来某种极为需要的调味剂。它既令人激动又很新（因此值得尝试），更别提它带来的那种责任感和可靠感。添加一项功能，然后有一个测试证明您做对了，这带来了某种神奇的成就感。
遗憾的是，宗教也渗入到了测试科学之中。您不必费力就能发现一些神圣的戒律或权威人士发出的指令，赞赏或斥责某些测试行为。
这本书试图提炼近几年来在Java测试领域中出现的一些精华。我们不曾领取薪水来推销测试，也没人强迫我们测试。在有的地方，一种方法学被宣布为获胜者，必须虔诚地奉行，我们都没在这样的地方工作过。
相反，我们是实用主义的测试者。测试对我们来说只是有价值的工具，帮助我们完成软件开发生命周期中的一部分工作。我们不是“受测试感染的人”，这个由JUnit在早期声明的术语已经广为流传。当我们觉得有意义的时候，就编写测试。对我们来说，测试是一种选择，不是一种传染病。
这种方式的结果是，我们注意到测试工具库中有一块很大的空白：很少有工具是从实际出发，能够方便地编写我们想写的那些测试。Java测试中的主要工具是JUnit，在许多情况下，它让我们很容易、很直接地考虑我们想执行的测试。但是，一个主要的障碍使它不能成为我们的工具，它不能反映我们想测试的代码中的一些更为深入的概念，例如，封装、状态共享、范围和顺序等。
尽管有许多缺点，但JUnit确实将测试的概念摆在了我们面前。它不再是一种随意而为的方法。相反，测试有了一个框架，并且有适用的测量标准。利用各种可视化工具，基于JUnit的测试可以很容易自动化，在多种环境下重复执行。这种易用性使得人们大量采用它，从总体上增强了Java测试的意识。
它的成功也扩展到了其他一些语言，它被移植到另一些语言上，底层的概念是相同的。
但是与任何其他成功的工具一样，成功是有代价的。微妙的焦点转移发生了，人们不再关注JUnit作为一项工具所支持的测试，而开始关注JUnit，如果有测试不能够符合它的狭小范围，人们会怀疑测试，而不是怀疑工具。
很多人会宣称，不能很容易地表达为一个简单“单元”的测试是有问题的测试。由于它的要求超出了JUnit所提供的简单功能，所以它不是一个单元测试。它是一项功能测试，应该在我们完成了单元构建块之后才发生。我们觉得这种论调让人迷惑不解。说到底，没有哪一种方法是进行测试的最佳方法。有人宣称开发必须从实现较小的完整单元开始，然后再思考更高层面的概念，这也是同样可笑。在有些情况下，这样做确实很有意义，但在另外一些情况下，这样做是没有意义的。测试是实现目标的手段，而目标是更好的软件。时刻记住这一点是很关键的。
为什么再写一本关于测试的书
这本书是关于Java测试的。您接下来读到的每一章每一节都会讨论这样或那样的测试。不论您使用哪种测试框架，或者使用了我们没有提到的工具，我们的目标都是向您展示我们试过有效的一些实践。我们也尝试根据自己的经验总结一些一般结论，并利用这些一般结论来推测将来可能出现的一些情况。
虽然我们在本书中利用TestNG来表达我们的思想，但是我们坚信，不论您是否使用JUnit，都会发现一些有用的内容，即使您不在Java平台上编程。有许多针对其他语言（如C#和C++）的类似TestNG和JUnit的框架，测试框架中包含的思想通常是普遍适用的，可以超越您所遇到的实现细节。
这本书是关于实用主义测试的。在本书中，您不会看到绝对的说法，没有根据的、宗教式的宣告，以及确保健壮代码的黄金法则。相反，我们总是试图展现每种情况的优缺点，因为归根到底，作为开发者的您才是对您面对的系统具有知识和经验的人。我们不能够在具体的事情上帮助您，但我们肯定可以向您展示解决常见问题的不同选择，让您来决定最合适的方法。
了解了这一点，让我们回到上面的问题：为什么再写一本关于测试的书？
关于Java测试有很多书，但仔细看时，我们认为几乎没有一本书包含了我们在日常工作中发现的、非常重要的一个宏大主题：现代Java测试。
是的，在一本书中使用“现代”这个形容词是很危险的，因为从本质上说，书籍不能够长久地保持“现代”。我们不认为这本书能逃过这一法则，但我们很清楚，已有的那些关于Java测试的书籍没有很好地处理Java开发者今天所面临的挑战。您可以在本书的目录中看到，我们介绍了大量的框架，其中许多是在最近三年内才出现的。
在我们对已有书籍的调查中，我们也意识到大多数Java测试的书籍使用了JUnit，它虽然是一个品质不错的测试框架，但是自从2001年以来，它就几乎没有做过任何改进JUnit 4在2006年发布，是5年以来JUnit的首次更新，但在本书编写时，它的采用仍然相当有限，因为大多数Java项目仍在使用JUnit 3。。我们不仅发现JUnit的年龄带来了一些局限性，而且发现它的设计目标也有局限性：JUnit是一个单元测试框架。如果试图用JUnit来做超出单元测试的工作（如测试在应用服务器中的一个真实servlet的部署），您可能就用错了工具。
最后，我们还介绍了一些刚刚开始被采用的新工具（如Guice）。我们相信这些工具与TestNG这样的现代测试框架一起使用时，具有很大的潜力，为我们打开了许多扇门，所以我们无法拒绝在书中介绍它们。希望我们对这些崭新框架的介绍能够为您的尝试带来一些方便。
在整本书中，我们都试图展示一种实用主义的应用程序测试方法。这本书介绍了许多模式。它们不是以清单的形式列出的，我们不希望读者将它们背下来，相反，它们仅仅是一组例子，确保您在面对测试代码时，找到正确的思考方法。
我们是通过两种独立的途径来做到这一点的。第一种途径是TestNG的用法说明。我们介绍它的大多数功能，解释这些功能是如何出现的、为何会出现，以及应用这些功能的实际例子。通过这种讨论，我们可以看到测试模式是如何通过测试框架来反映的，什么是健壮的、可维护的测试套件。
第二种途径是展示TestNG如何与现有的代码以及大量的Java框架和库集成。很少有人会有幸做一个完全从头开始的项目。总有一些组件需要复用或集成，有一些遗留的子系统需要调用，或者需要考虑向下兼容的问题。为了支持测试而要求重新设计或重写是很愚蠢的。相反，我们试图展示如何能够与已有的代码集成，小的增量式的改动如何能够让代码变得更加可测试，随时间推移而变得更健壮。同样，通过这种方式，一些模式出现了，其中也包含了关于如何编写测试更多实践和进行测试的一般方法。
我们希望您在阅读本书时得到享受，就像我们在编写本书时得到享受一样。我们对测试有强烈的感情，但同样强烈地感受到，在各种钉子的世界里不存在一把金锤子。虽然有些人宁愿相信这一点，但是实际上没有哪种方法或解决方案能够让您不必思考，不必理解您的目标，就确保您的测试过程是理性的、考虑周全的。
本书读者
那么，这本书是写给谁的呢？简而言之，它是写给对测试感兴趣的Java开发者的。
我们的目标也包括这样一些开发者，他们已经对代码进行了一段时间的测试（使用JUnit或其他框架），但仍然发现自己有时候被代码明显的复杂性、范围或测试的工作量吓住了。在TestNG社区的帮助下，这些年来，我们对测试各种Java代码时形成的一些最佳实践的理解有了很大的提高。我们希望这本书充分地讨论这些最佳实践，这样大家在遇到测试问题时不会不知所措。
这本书使用了TestNG来编写示例代码，如果您还不是TestNG的用户，不要被吓住了：许多的原则很容易在最新版本的JUnit中采用（或移植）。
不论您是否使用TestNG，我们都希望您读完这本书时，会学到一些测试Java代码的新技术，将来能够正确地应用。致谢
在编写这本书的过程中，许多人为我们提供了帮助，在此对他们表示感谢。
首先，我们要感谢Alexandru Popescu，感谢他从很早就开始在TestNG上不知疲倦地工作，感谢他对用户的绝对奉献精神。没有他，TestNG不会像今天这样。
有些人帮助我们检查了本书的草稿，他们发现了许多错误和不准确的地方，如果不是他们，我们就会漏过这些问题。按照字母顺序，我们要向以下人员表达特殊的“QA感谢”：Tom Adams、Mike Aizatsky、Kevin Bourrillion、Brian Goetz、Erik Koerber、Tim McNerney、Bill Michell、Brian Slesinsky、James Strachan和Joe Walnes。
我们也要特别感谢Bob Lee和Patrick Linskey，在过去的几年里，他们经常与我们讨论许多问题，这些讨论最终以某种方式影响了TestNG （和这本书）。
如果没有TestNG邮件列表中的这些人，这一切都不可能发生了。这些年来，他们提供了鼓励、洞见、补丁和用例，以及足够多的建设性批评意见，帮助我们优化在测试领域的想法和思考，这一切对我们的帮助无法估量。
Hani要感谢他的父母、兄弟姐妹（Sara、Ghalib、Khalid和May）、妻子（Terry）和那帮Lost剧迷们——这些人忍住嘲笑指出写完这本书是多么不可能的一件事情。
Cédric要感谢他的妻子Anne Marie，在编写这本书的过程中，她付出了耐心和支持。
最后，特别提一下，“不要感谢”暴雪公司，魔兽世界的发布者，没有它这本书要容易写得多。
Cédric 和Hani
企业级Java开发者必须实现更宽、更深的测试覆盖率，除了单元测试之外，还需要实现功能测试、集成测试和系统验收测试。本书介绍了突破性的Java测试技术和TestNG,后者是一个强大的开放源代码Java测试平台。 C?dric Beust是TestNG的创始人，他和一流的Java开发者Hani Suleiman，向我们展示了一些强大的、灵活的测试模式 ，这些测试模式基本上可以适用于任何测试工具、框架或语言。他们展示了如何利用关键的Java平台改进来促进有效的测试，如依赖注入和模拟对象。还全面地介绍了TestNG，展示了它如何克服以前框架的一些局限以及如何利用新的技术，从而使得测试复杂的软件系统变得更容易。 本书讲求实用主义并关注结果，将帮助Java开发者为今天的关键任务环境创建更健壮的代码。 本书主要内容包括： ■ 展示了与测试有关的折衷考虑，这样您就能在测试什么和怎么测试方面做出更好的决定。 ■ 介绍了TestNG，说明了它的目标和功能，并展示了如何在真实的环境中应用这些功能。 ■ 展示了如何集成TestNG和已有的代码、开发框架以及软件库。 ■ 展示了如何测试关键代码的特征，如封装、共享状态、范围和线程安全。 ■ 展示了如何测试应用程序元素，包括Java EE APIs、数据库、Web页面和XML文件。 ■ 展示了高级技术：测试部分失败、工厂、依赖关系测试、远程调用、基于集群的测试服务器群等。 ■ 介绍了在Eclipse和IDE中安装TestNG插件。 ■ 包含了大量的代码示例。 无论您使用TestNG、JUnit或其他测试框架，本书提供的测试设计模式都会告诉您如何改进您的测试，对如何让代码和设计变得更可测试提供具体的建议。
做正确的事情从来就不容易。我们大多数人可能应该更合理地饮食，进行更多的锻炼，花更多的时间和家人在一起。但是每天，当面对做容易的事还是做正确的事的选择时，我们常常选择容易的事，因为这些事更容易一些。
对于软件测试也是一样。虽然我们都知道更多的测试会让我们的代码更可靠、更可维护，我们应该在测试上花费更多的精力，而且如果这么做，用户也会感谢我们，从而帮助我们更好地理解自己的程序，但是每天当我们坐在计算机前，面对编写更多测试还是更多应用程序代码的选择时，还是很想选择更容易的事情做。
今天，大多数人都已承认单元测试是开发者的职责，而不是QA的职责。对此，我们要感谢JUnit测试框架。JUnit之所以产生这样大的冲击，是因为它实在没有太多的东西——它是一个简单的框架，没有多少代码。JUnit改变了开发者的行为，而成年累月的说教和过错都没有做到这一点，这其中最重要的原因就是，编写单元测试的痛苦被减少到了可以忍受的程度，让我们实际上有可能将单元测试包含在日常编码工作中。JUnit没有激发编写测试的渴望，这是不太容易让人接受的，它只是让我们能够在做正确的事情时更容易。
随着新形成的这些正确观点，许多开发者宣称他们对测试充满热情，自豪地将自己称为“受测试感染的人”。这都很好，很少有人会说软件开发者做了太多的测试，所以更多的测试可能是一种进步。但是，这只是第一步。除了单元测试之外，还有更多的测试，如果希望开发者再深入一步，我们必须提供一些测试工具来减少创建这些测试的痛苦，并且将可测试性作为一项基本的设计要求。如果软件工程打算成为真正的工程实践，测试就将成为支撑它的一根关键支柱。（也许有一天，编写没有测试的代码会被认为是没有职业负责精神的做法，就像造桥时不进行结构分析一样。）
这本书基于的观点是，我们刚刚才开始进行负责任的测试。TestNG（NG的意思是“下一代”）项目的目标是帮助开发者再深入一步，让我们能进行范围更广、更深入的测试，不仅包括单元测试，还包括验收测试、功能测试和集成测试。它提供了许多有用的特征，其中包括指定测试套件和向测试套件传递参数的丰富机制，支持并发测试，以及解除测试代码及其数据源的耦合的机制。它的一些功能被最近的JUnit版本吸收了，这也证明了TestNG的成功。
不论提供什么工具，进行更有效的开发者测试存在一项挑战，即对于编写有效的测试与编写有效的产品代码来说，对技能的要求是不一样的。但是和大多数技能一样，测试技能是可以习得的，最好的学习方式就是看看更有经验的人是如何做的。在这本书中，Hani和Cédric针对有效测试Java应用程序以及围绕可测试性来设计应用程序和组件，分享了他们喜爱的技术。最后一项技术（围绕可测试性来设计）可能是这本书中最有价值的经验之一。围绕可测试性来设计代码迫使您更早地思考组件间的交互和依赖关系，从而鼓励您创建更干净、更松耦合的代码。当然，书中利用了TestNG来展示这些技术，但即使您不是TestNG的用户（也不想成为一名TestNG的用户），这里展现的实用技术也将帮助您更好地测试，从而更好地进行软件工程。
Brian GoetzSenior Staff Engineer, Sun Microsystems
Cedric Beust;Hani Suleiman：Cedric Beust: 是Google的高级软件工程师，也是Java开发社区的一名积极成员，广泛参与了最新Java版本的开发。他是TestNG项目的发起人和主要贡献者。
Hani Suleiman: 是Formicary公司的CTO，这是一家专注于财务应用程序的咨询和门户软件公司。他是Java开发社区执行委员会的两名独立成员之一。
王海鹏：暂无简介
软件开发是一项风险事业。测试则是缓解项目风险最重要的手段之一。一般来说，我们应该让需求可测试，让测试自动化，让自动化测试变得容易。
本书作者采用的是实用主义的方式，这一点对于真实项目的开发者帮助特别大。没有教条式的金科玉律，有的是更多实际可行的平衡和折衷。作者在我们面前展现了多姿多彩的Java企业级应用开发的实景，介绍了他们以及TestNG用户社区的实际开发经验和测试经验。在开发中，我们也许要和300万行遗留代码打交道，要和启动缓慢的应用服务器、数据库服务器打交道，要和各式各样、不断涌现的复用组件和库打交道，我们的生活充满了挑战。在本书中，您会看到世界一流的开发者是如何应对这些挑战的。
Java的开发社区充满了创新。这些创新者都有一个良好的愿望，让好的思想和工具为尽可能多的人提供帮助。TestNG的作者也是一样，所以本书既包含了理性的思考，也包含了善良的祝福：您可以更高效地完成项目，然后有更多的时间来锻炼身体或陪伴家人（或玩魔兽世界）。
理念一定要先进，工具一定要先进。将这些先进的理念和工具应用于项目中，超过社会平均的生产效率，这就是创新的意义所在。
JUnit让开发者编写测试的概念深入人心，TestNG则将我们的视野扩展到所有的测试，不仅仅是单元测试，还有集成测试、系统测试、功能测试、验收测试、压力测试……我相信，这本书将会给Java开发者带来诸多帮助。
本书由王海鹏负责翻译，参加本书翻译工作的人员还有：王海燕、李国安、周建鸣、范俊、张海洲、谢伟奇、林冀、钱立强、甘莉萍。在本书的翻译过程中，我学到了很多，因此郑重地向大家推荐它。如果这本书对于您改进软件开发实践有所帮助，我将十分高兴。
王海鹏
戊子年初夏于上海
译者序
序
前言
致谢
第1章起步 1
1.1超越JUnit 3 2
1.1.1有状态的类 2
1.1.2参数 3
1.1.3基类 3
1.1.4异常并非偶然 3
1.1.5执行测试 4
1.1.6真实世界中的测试 4
1.1.7配置方法 4
1.1.8依赖关系 5
1.1.9领悟 5
1.2JUnit 4 5
1.3针对可测试性而设计 6
1.3.1面向对象编程和封装 6
1.3.2设计模式革命 7
1.3.3确定问题 7
1.3.4推荐阅读 11
1.4TestNG 12
1.4.1annotation 12
1.4.2测试、套件和配置annotation 13
1.4.3分组 14
1.4.4testng.xml 15
1.5本章小结 15
第2章测试设计模式 16
2.1针对失败而测试 16
2.1.1报告错误 16
2.1.2运行时刻异常和被检查的异常 17
2.1.3测试代码是否漂亮地处理了失败 18
2.1.4何时不要使用expected-
Exceptions 21
2.1.5testng-failed.xml 22
2.2工厂 24
2.2.1@Factory 24
2.2.2org.testng.ITest 27
2.3数据驱动测试 27
2.3.1参数和测试方法 29
2.3.2利用testng.xml传递参数 31
2.3.3利用@DataProvider传递参数 32
2.3.4针对数据提供者的参数 35
2.3.5Method参数 35
2.3.6ITestContext参数 36
2.3.7延迟数据提供者 38
2.3.8两种方法的优点和不足 41
2.3.9提供数据 42
2.3.10数据提供者还是工厂 43
2.3.11综合运用 43
2.4异步测试 46
2.5测试多线程代码 49
2.5.1并发测试50
2.5.2threadPoolSize、invocationCount和timeOut52
2.5.3并发执行54
2.5.4打开并行位57
2.6性能测试58
2.6.1算法复杂度58
2.6.2测试复杂度60
2.7模拟和桩62
2.7.1模拟与桩的对比63
2.7.2为可模拟性而设计66
2.7.3模拟库67
2.7.4选择正确的策略69
2.7.5模拟易犯的错误70
2.8依赖的测试71
2.8.1依赖的代码72
2.8.2利用TestNG进行依赖的测试73
2.8.3决定依赖于组还是方法74
2.8.4依赖的测试和线程76
2.8.5配置方法的失败77
2.9继承和annotation范围78
2.9.1问题78
2.9.2继承易犯的错误80
2.10测试分组82
2.10.1语法83
2.10.2分组与运行时刻84
2.10.3执行分组87
2.10.4有效使用分组87
2.11代码覆盖率91
2.11.1覆盖率示例92
2.11.2覆盖率度量指标93
2.11.3覆盖率工具94
2.11.4实现101
2.11.5小心102
2.11.6成功使用覆盖率的建议102
2.12本章小结104
第3章企业级测试105
3.1典型企业级场景105
3.1.1参与者106
3.1.2测试方法学106
3.1.3当前方法的问题107
3.2一个具体例子108
3.2.1测试内容109
3.2.2非测试内容109
3.3测试实现110
3.3.1测试成功场景110
3.3.2构建测试数据112
3.3.3测试准备问题114
3.3.4错误处理118
3.3.5逐渐出现的单元测试120
3.3.6处理容器内的组件122
3.3.7综述123
3.4探讨竞争消费者模式125
3.4.1模式125
3.4.2测试126
3.5重构的作用128
3.5.1一个具体的例子129
3.5.2容器内的方式133
3.6本章小结134
第4章Java EE测试135
4.1容器内测试与容器外测试的对比136
4.2容器内测试137
4.2.1创建测试环境137
4.2.2确定测试137
4.2.3注册测试139
4.2.4注册结果监听者140
4.3Java命名和目录接口（JNDI）142
4.3.1理解JNDI的自举过程142
4.3.2Spring的SimpleNamingContext-
Builder143
4.3.3避免JNDI 144
4.4Java数据库连接（JDBC）144
4.4.1c3p0 146
4.4.2Commons DBCP 146
4.4.3Spring 146
4.5Java事务API（JTA）147
4.5.1Java Open Transaction Manager
（JOTM）149
4.5.2Atomikos TransactionEssentials 149
4.6Java消息服务（JMS）150
4.6.1创建发送者/接收者测试 152
4.6.2在测试中使用ActiveMQ 155
4.7Java持久API（JPA）155
4.7.1配置数据库 156
4.7.2配置JPA提供者 157
4.7.3编写测试 158
4.7.4模拟一个容器 159
4.7.5将Spring作为容器 160
4.8Enterprise JavaBeans 3.0（EJB3） 163
4.8.1消息驱动Bean 164
4.8.2会话Bean 165
4.8.3另一个Spring容器 168
4.8.4全功能容器的不足之处 169
4.9Java API for XML Web Services
（JAX-WS） 170
4.9.1记录请求 171
4.9.2准备测试环境 172
4.9.3创建服务测试 174
4.9.4XPath测试 175
4.9.5测试远程服务 176
4.10servlet 177
4.10.1容器内测试 177
4.10.2模拟对象/桩对象 177
4.10.3重构 178
4.10.4嵌入的容器 178
4.10.5内存中调用 180
4.11XML 182
4.11.1使用dom4j 183
4.11.2使用XMLUnit 183
4.12本章小结 184
第5章集成 186
5.1Spring 186
5.1.1Spring的测试包功能 187
5.1.2测试类层次结构 188
5.2Guice 193
5.2.1Spring的问题 194
5.2.2认识Guice 195
5.2.3一个典型的依赖场景 195
5.2.4对象工厂 197
5.2.5Guice配置 198
5.2.6基于Guice的测试 201
5.2.7对测试依赖进行分组 202
5.2.8注入配置 203
5.3DbUnit 205
5.3.1配置 205
5.3.2用法 206
5.3.3验证结果 208
5.4HtmlUnit 211
5.4.1配置 212
5.4.2用法 213
5.5Selenium 216
5.6Swing UI测试 217
5.6.1测试方法 217
5.6.2配置 218
5.6.3用法 219
5.7针对画图代码的测试 221
5.8持续集成 223
5.8.1为何要持续集成 223
5.8.2CI服务器的功能 224
5.8.3TestNG集成 224
5.9本章小结 225
第6章扩展TestNG 226
6.1TestNG API 226
6.1.1org.testng.TestNG、ITestResult、
ITestListener、ITestNGMethod 226
6.1.2一个具体的例子 228
6.1.3XML API 230
6.1.4合成XML文件 232
6.2BeanShell 233
6.2.1BeanShell概述 233
6.2.2TestNG与BeanShell 234
6.2.3交互式执行 236
6.3方法选择器 237
6.4annotation转换器 241
6.4.1annotation历史 241
6.4.2优点和不足 242
6.4.3使用TestNG annotation
转换器 242
6.4.4annotation转换器的可能用法 246
6.5报告 247
6.5.1默认报告 247
6.5.2报告API 251
6.5.3报告插件API 251
6.6编写自定义annotation 256
6.6.1实现 257
6.6.2测试 260
6.7本章小结 262
第7章杂谈 263
7.1动机 263
7.2TestNG哲学 263
7.3关注和提供异常 264
7.4有状态的测试 266
7.4.1不可修改的状态 267
7.4.2可修改的状态 267
7.5测试驱动开发的缺点 268
7.5.1TDD注重微观设计超过宏观
设计 268
7.5.2TDD难以应用 269
7.5.3从测试驱动开发中汲取优点 270
7.6测试私有方法 270
7.7测试与封装 272
7.8调试器的威力 273
7.9记日志的最佳实践 274
7.10时间的价值 276
7.11本章小结 278
附录AIDE集成 279
附录BTestNG Javadocs 295
附录Ctestng.xml 302
附录D从JUnit迁移 310
