Java测试新技术:TestNG和高级概念
基本信息
- 作者: Cedric Beust Hani Suleiman [作译者介绍]
- 译者: 王海鹏
- 丛书名: 华章程序员书库
- 出版社:机械工业出版社
- ISBN:9787111245506
- 上架时间:2008-10-20
- 出版日期:2009 年1月
- 开本:16开
- 页码:324
- 版次:1-1
- 所属分类:
计算机 > 软件与程序设计 > JAVA(J#) > 综合
编辑推荐
TestNG创始人最新力作。.
介绍了大量新的测试模式和一些新工具。..
以实例展示测试模式。...
内容简介回到顶部↑
本书介绍了java测试的新技术,主要内容包括:基本概念、测试设计模式、企业级测试、java ee测试、集成和扩展testng等。本书通过针对有效测试java应用程序以及围绕可测试性来设计应用程序和组件展示了这些有效的测试技术,并给出了每种测试方法的优点和不足,展示了解决常见问题的不同选择。
本书注重实际应用,适合对测试感兴趣的java开发者参考阅读。
本书注重实际应用,适合对测试感兴趣的java开发者参考阅读。
目录回到顶部↑
序
前言
致谢
第1章 起步
1.1 超越junit 3
1.2 junit 4
1.3 针对可测试性而设计
1.4 testng
1.5 本章小结
第2章 测试设计模式
2.1 针对失败而测试
2.2 工厂
2.3 数据驱动测试
2.4 异步测试
2.5 测试多线程代码
2.6 性能测试
2.7 模拟和桩
2.8 依赖的测试
2.9 继承和annotation范围
2.10 测试分组
前言
致谢
第1章 起步
1.1 超越junit 3
1.2 junit 4
1.3 针对可测试性而设计
1.4 testng
1.5 本章小结
第2章 测试设计模式
2.1 针对失败而测试
2.2 工厂
2.3 数据驱动测试
2.4 异步测试
2.5 测试多线程代码
2.6 性能测试
2.7 模拟和桩
2.8 依赖的测试
2.9 继承和annotation范围
2.10 测试分组
译者序回到顶部↑
软件开发是一项风险事业。测试则是缓解项目风险最重要的手段之一。一般来说,我们应该让需求可测试,让测试自动化,让自动化测试变得容易。.
本书作者采用的是实用主义的方式,这一点对于真实项目的开发者帮助特别大。没有教条式的金科玉律,有的是更多实际可行的平衡和折衷。作者在我们面前展现了多姿多彩的Java企业级应用开发的实景,介绍了他们以及TestNG用户社区的实际开发经验和测试经验。在开发中,我们也许要和300万行遗留代码打交道,要和启动缓慢的应用服务器、数据库服务器打交道,要和各式各样、不断涌现的复用组件和库打交道,我们的生活充满了挑战。在本书中,您会看到世界一流的开发者是如何应对这些挑战的。..
Java的开发社区充满了创新。这些创新者都有一个良好的愿望,让好的思想和工具为尽可能多的人提供帮助。TestNG的作者也是一样,所以本书既包含了理性的思考,也包含了善良的祝福:您可以更高效地完成项目,然后有更多的时间来锻炼身体或陪伴家人(或玩魔兽世界)。
理念一定要先进,工具一定要先进。将这些先进的理念和工具应用于项目中,超过社会平均的生产效率,这就是创新的意义所在。
JUnit让开发者编写测试的概念深入人心,TestNG则将我们的视野扩展到所有的测试,不仅仅是单元测试,还有集成测试、系统测试、功能测试、验收测试、压力测试……我相信,这本书将会给Java开发者带来诸多帮助。
本书由王海鹏负责翻译,参加本书翻译工作的人员还有:王海燕、李国安、周建鸣、范俊、张海洲、谢伟奇、林冀、钱立强、甘莉萍。在本书的翻译过程中,我学到了很多,因此郑重地向大家推荐它。如果这本书对于您改进软件开发实践有所帮助,我将十分高兴。...
王海鹏
戊子年初夏于上海
本书作者采用的是实用主义的方式,这一点对于真实项目的开发者帮助特别大。没有教条式的金科玉律,有的是更多实际可行的平衡和折衷。作者在我们面前展现了多姿多彩的Java企业级应用开发的实景,介绍了他们以及TestNG用户社区的实际开发经验和测试经验。在开发中,我们也许要和300万行遗留代码打交道,要和启动缓慢的应用服务器、数据库服务器打交道,要和各式各样、不断涌现的复用组件和库打交道,我们的生活充满了挑战。在本书中,您会看到世界一流的开发者是如何应对这些挑战的。..
Java的开发社区充满了创新。这些创新者都有一个良好的愿望,让好的思想和工具为尽可能多的人提供帮助。TestNG的作者也是一样,所以本书既包含了理性的思考,也包含了善良的祝福:您可以更高效地完成项目,然后有更多的时间来锻炼身体或陪伴家人(或玩魔兽世界)。
理念一定要先进,工具一定要先进。将这些先进的理念和工具应用于项目中,超过社会平均的生产效率,这就是创新的意义所在。
JUnit让开发者编写测试的概念深入人心,TestNG则将我们的视野扩展到所有的测试,不仅仅是单元测试,还有集成测试、系统测试、功能测试、验收测试、压力测试……我相信,这本书将会给Java开发者带来诸多帮助。
本书由王海鹏负责翻译,参加本书翻译工作的人员还有:王海燕、李国安、周建鸣、范俊、张海洲、谢伟奇、林冀、钱立强、甘莉萍。在本书的翻译过程中,我学到了很多,因此郑重地向大家推荐它。如果这本书对于您改进软件开发实践有所帮助,我将十分高兴。...
王海鹏
戊子年初夏于上海
前言回到顶部↑
我们都在进行软件开发:编写代码,然后部署。当部署了代码之后,客户会表现高兴或不高兴。令人沮丧的是,他们经常表现得不高兴。.
在过去的几十年里,人们为了减少这种不高兴编写了许多东西。我们有无数种语言、方法学、工具、管理技术和老式秘方,来帮助处理这个问题。
其中有些方法很有效。最近,人们将关注的重点重新放到了测试上,据说测试将给开发者和用户带来欢乐。
人们写了很多东西来赞美测试的优点。它可以让您的代码更好、更快、更轻。它可以为编码这样的乏味工作带来某种极为需要的调味剂。它既令人激动又很新(因此值得尝试),更别提它带来的那种责任感和可靠感。添加一项功能,然后有一个测试证明您做对了,这带来了某种神奇的成就感。
遗憾的是,宗教也渗入到了测试科学之中。您不必费力就能发现一些神圣的戒律或权威人士发出的指令,赞赏或斥责某些测试行为。
这本书试图提炼近几年来在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的年龄带来了一些局限性,而且发现它的设计目标也有局限性:JUnit是一个单元测试框架。如果试图用JUnit来做超出单元测试的工作(如测试在应用服务器中的一个真实servlet的部署),您可能就用错了工具。
在过去的几十年里,人们为了减少这种不高兴编写了许多东西。我们有无数种语言、方法学、工具、管理技术和老式秘方,来帮助处理这个问题。
其中有些方法很有效。最近,人们将关注的重点重新放到了测试上,据说测试将给开发者和用户带来欢乐。
人们写了很多东西来赞美测试的优点。它可以让您的代码更好、更快、更轻。它可以为编码这样的乏味工作带来某种极为需要的调味剂。它既令人激动又很新(因此值得尝试),更别提它带来的那种责任感和可靠感。添加一项功能,然后有一个测试证明您做对了,这带来了某种神奇的成就感。
遗憾的是,宗教也渗入到了测试科学之中。您不必费力就能发现一些神圣的戒律或权威人士发出的指令,赞赏或斥责某些测试行为。
这本书试图提炼近几年来在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的年龄带来了一些局限性,而且发现它的设计目标也有局限性:JUnit是一个单元测试框架。如果试图用JUnit来做超出单元测试的工作(如测试在应用服务器中的一个真实servlet的部署),您可能就用错了工具。
序言回到顶部↑
做正确的事情从来就不容易。我们大多数人可能应该更合理地饮食,进行更多的锻炼,花更多的时间和家人在一起。但是每天,当面对做容易的事还是做正确的事的选择时,‘我们常常选择容易的事,因为这些事更容易一些。.
对于软件测试也是一样。虽然我们都知道更多的测试会让我们的代码更可靠、更可维护,我们应该在测试上花费更多的精力,而且如果这么做,用户也会感谢我们,从而帮助我们更好地理解自己的程序,但是每天当我们坐在计算机前,面对编写更多测试还是更多应用程序代码的选择时,还是很想选择更容易的事情做。
今天,大多数人都已承认单元测试是开发者的职责,而不是QA的职责。对此,我们要感谢JUnit测试框架。JUnit之所以产生这样大的冲击,是因为它实在没有太多的东西——它是一个简单的框架,没有多少代码。JUnit改变了开发者的行为,而成年累月的说教和过错都没有做到这一点,这其中最重要的原因就是,编写单元测试的痛苦被减少到了可以忍受的程度,让我们实际上有可能将单元测试包含在日常编码工作中。JUnit没有激发编写测试的渴望,这是不太容易让人接受的,它只是让我们能够在做正确的事情时更容易。
随着新形成的这些正确观点,许多开发者宣称他们对测试充满热情,自豪地将自己称为“受测试感染的人”。这都很好,很少有人会说软件开发者做了太多的测试,所以更多的测试可能是一种进步。但是,这只是第一步。除了单元测试之外,还有更多的测试,如果希望开发者再深入一步,我们必须提供一些测试工具来减少创建这些测试的痛苦,并且将可测试性作为一项基本的设计要求。如果软件工程打算成为真正的工程实践,测试就将成为支撑它的一根关键支柱。(也许有一天,编写没有测试的代码会被认为是没有职业负责精神的做法,就像造桥时不进行结构分析一样。)..
这本书基于的观点是,我们刚刚才开始进行负责任的测试。TestNG(NG的意思是“下一代”)项目的目标是帮助开发者再深入一步,让我们能进行范围更广、更深入的测试,不仅包括单元测试,还包括验收测试、功能测试和集成测试。它提供了许多有用的特征,其中包括指定测试套件和向测试套件传递参数的丰富机制,支持并发测试,以及解除测试代码及其数据源的耦合的机制。它的一些功能被最近的JUnit版本吸收了,这也证明了TestNG的成功。
不论提供什么工具,进行更有效的开发者测试存在一项挑战,即对于编写有效的测试与编写有效的产品代码来说,对技能的要求是不一样的。但是和大多数技能一样,测试技能是可以习得的,最好的学习方式就是看看更有经验的人是如何做的。在这本书中,Hani和Cedric针对有效测试Java应用程序以及围绕可测试性来设计应用程序和组件,分享了他们喜爱的技术。最后一项技术(围绕可测试性来设计)可能是这本书中最有价值的经验之一。围绕可测试性来设计代码迫使您更早地思考组件间的交互和依赖关系,从而鼓励您创建更干净、更松耦合的代码。当然,书中利用了TestNG来展示这些技术,但即使您不是TestNG的用户(也不想成为一名TestNG的用户),这里展现的实用技术也将帮助您更好地测试,从而更好地进行软件工程。...
Brian Goetz
Senior Staff Engineer,Sun Microsystems
对于软件测试也是一样。虽然我们都知道更多的测试会让我们的代码更可靠、更可维护,我们应该在测试上花费更多的精力,而且如果这么做,用户也会感谢我们,从而帮助我们更好地理解自己的程序,但是每天当我们坐在计算机前,面对编写更多测试还是更多应用程序代码的选择时,还是很想选择更容易的事情做。
今天,大多数人都已承认单元测试是开发者的职责,而不是QA的职责。对此,我们要感谢JUnit测试框架。JUnit之所以产生这样大的冲击,是因为它实在没有太多的东西——它是一个简单的框架,没有多少代码。JUnit改变了开发者的行为,而成年累月的说教和过错都没有做到这一点,这其中最重要的原因就是,编写单元测试的痛苦被减少到了可以忍受的程度,让我们实际上有可能将单元测试包含在日常编码工作中。JUnit没有激发编写测试的渴望,这是不太容易让人接受的,它只是让我们能够在做正确的事情时更容易。
随着新形成的这些正确观点,许多开发者宣称他们对测试充满热情,自豪地将自己称为“受测试感染的人”。这都很好,很少有人会说软件开发者做了太多的测试,所以更多的测试可能是一种进步。但是,这只是第一步。除了单元测试之外,还有更多的测试,如果希望开发者再深入一步,我们必须提供一些测试工具来减少创建这些测试的痛苦,并且将可测试性作为一项基本的设计要求。如果软件工程打算成为真正的工程实践,测试就将成为支撑它的一根关键支柱。(也许有一天,编写没有测试的代码会被认为是没有职业负责精神的做法,就像造桥时不进行结构分析一样。)..
这本书基于的观点是,我们刚刚才开始进行负责任的测试。TestNG(NG的意思是“下一代”)项目的目标是帮助开发者再深入一步,让我们能进行范围更广、更深入的测试,不仅包括单元测试,还包括验收测试、功能测试和集成测试。它提供了许多有用的特征,其中包括指定测试套件和向测试套件传递参数的丰富机制,支持并发测试,以及解除测试代码及其数据源的耦合的机制。它的一些功能被最近的JUnit版本吸收了,这也证明了TestNG的成功。
不论提供什么工具,进行更有效的开发者测试存在一项挑战,即对于编写有效的测试与编写有效的产品代码来说,对技能的要求是不一样的。但是和大多数技能一样,测试技能是可以习得的,最好的学习方式就是看看更有经验的人是如何做的。在这本书中,Hani和Cedric针对有效测试Java应用程序以及围绕可测试性来设计应用程序和组件,分享了他们喜爱的技术。最后一项技术(围绕可测试性来设计)可能是这本书中最有价值的经验之一。围绕可测试性来设计代码迫使您更早地思考组件间的交互和依赖关系,从而鼓励您创建更干净、更松耦合的代码。当然,书中利用了TestNG来展示这些技术,但即使您不是TestNG的用户(也不想成为一名TestNG的用户),这里展现的实用技术也将帮助您更好地测试,从而更好地进行软件工程。...
Brian Goetz
Senior Staff Engineer,Sun Microsystems
书摘回到顶部↑
第1章 起步
1.1 超越JUnit 3
像大多数Java开发者一样,我们使用JUnit的历史已经很长了,我们当然相信它使我们的测试更可靠健壮。但是这些年来,我们也遇到了这个框架中的一些不足,至少我们认为是这样的。
……
1.1 超越JUnit 3
像大多数Java开发者一样,我们使用JUnit的历史已经很长了,我们当然相信它使我们的测试更可靠健壮。但是这些年来,我们也遇到了这个框架中的一些不足,至少我们认为是这样的。
……

点击看大图






加载中...
