JUnit实施.doc

JUnit 实施 eric 1. 测试的概念 2. 回归测试框架-JUnit 3. Design by Contract 4. Refactoring 5. IDE 对 JUnit 的支持 6. JUnit 简介 1. 安装 2. Fixture 3. TestCase 4. TestSuite 5. TestRunner 7. JUnit 最佳实践 8. JUnit 与 J2EE 1. 测试的概念长期以来,我所接触的软件开发人员很少有人能在开发的过程中进行测试工作。大部分的项目都是在最终验收的时候编写测试文档。有些项目甚至没有测试文档。现在情况有了改变。我们一直提倡 UML 、 RUP 、软件工程、 CMM ,目的只有一个,提高软件编写的质量。举一个极端的例子:如果你是一个超级程序设计师,一个传奇般的人物。(你可以一边喝咖啡,一边听着音乐,同时编写这操作系统中关于进程调度的模块,而且两天时间内就完成了!) 我真得承认, 有这样的人。( 那个编写 UNI X 中的 vi 编辑器的家伙就是这种人。)然而非常遗憾的是这些神仙们并没有留下如何修成正果的 README 。所以我们这些凡人--在同一时间只能将注意力集中到若干点(据科学统计,我并不太相信,一般的人只能同时考虑最多 7 个左右的问题,高手可以达到 12 个左右) ,而不能既纵览全局又了解细节--只能期望于其他的方式来保证我们所编写的软件质量。为了说明我们这些凡人是如何的笨。有一个聪明人提出了软件熵( software entropy ) 的概念: 一个程序从设计很好的状态开始,随着新的功能不断地加入,程序逐渐地失去了原有的结构,最终变成了一团乱麻。你可能会争辩, 在这个例子中, 设计很好的状态实际上并不好, 如果好的话,就不会发生你所说的情况。是的,看来你变聪明了,可惜你还应该注意到两个问题: 1) 我们不能指望在恐龙纪元(大概是十年前)设计的结构到了现在也能适用吧。 2) 拥有签字权的客户代表可不理会加入一个新功能是否会对软件的结构有什么影响,即便有影响也是程序设计人员需要考虑的问题。如果你拒绝加入这个你认为致命的新功能,那么你很可能就失去了你的住房贷款和面包(对中国工程师来说也许是米饭或面条, 要看你是南方人还是北方人)。另外,需要说明的是我看过的一些讲解测试的书都没有我写的这么有人情味(不好意思... )。我希望看到这片文章的兄弟姐妹能很容易地接受测试的概念,并付诸实施。所以有些地方写的有些夸张,欢迎对测试有深入理解的兄弟姐妹能体察民情,并不吝赐教。好了,我们现在言归正传。要测试,就要明白测试的目的。我认为测试的目的很简单也极具吸引力:写出高质量的软件并解决软件熵这一问题。想象一下,如果你写的软件和 Richard Stallman ( GNU 、 FSF 的头儿)写的一样有水准的话,是不是很有成就感?如果你一致保持这种高水准,我保证你的薪水也会有所变动。测试也分类,白箱测试、黑箱测试、单元测试、集成测试、功能测试... 。我们先不管有多少分类,如何分类。先看那些对我们有用的分类,关于其他的测试,有兴趣的人可参阅其他资料。白箱测试是指在知道被测试的软件如何( How ) 完成功能和完成什么样( What ) 的功能的条件下所作的测试。一般是由开发人员完成。因为开发人员最了解自己编写的软件。本文也是以白箱测试为主。黑箱测试则是指在知道被测试的软件完成什么样( What ) 的功能的条件下所作的测试。一般是由测试人员完成。黑箱测试不是我们的重点。本文主要集中在单元测试上,单元测试是一种白箱测试。目的是验证一个或若干个类是否按所设计的那样正常工作。集成测试则是验证所有的类是否能互相配合, 协同完成特定的任务, 目前我们暂不关心它。下面我所提到的测试,除非特别说明,一般都是指单元测试。需要强调的是:测试是一个持续的过程。也就是说测试贯穿与开发的整个过程中,单元测试尤其适合于迭代增量式( iterative and incremental ) 的开发过程。 Martin Fowler ( 有点儿像引用孔夫子的话) 甚至认为: “在你不知道如何测试代码之前,就不应该编写程序。而一旦你完成了程序,测试代码也应该完成。除非测试成功,你不能认为你编写出了可以工作的程序。”我并不指望所有的开发人员都能有如此高的觉悟,这种层次也不是一蹴而就的。但我们一旦了解测试的目的和好处,自然会坚持在开发过程中引入测试。因为我们是测试新手,我们也不理会那些复杂的测试原理, 先说一说最简单的: 测试就是比较预期的结果是否与实际执行的结果一致。如果一致则通过,否则失败。看下面的例子: //将要被测试的类 public class Car {public int getWheels (){return 4;