主流版本控制工具介绍
    现在，有很多优秀的版本控制工具供我们选择，下面就五种主流的版本控制工具做简单的介绍。
Starteam
    是一个集合了版本控制、构建管理（Build Management）和缺陷跟踪系统为一体的软件，并且具有强大的图形界面，易学易用；但管理复杂、维护困难。2002年底被Borland公司收购。
PVCS Version Manager
     是美国的MERANT公司软件配置管理工具PVCS 家族中的一个组成部分，它能够实现源代码、可执行文件、应用文件、图形文件和文档的版本管理；它能安全地支持软件并行开发，对多个软件版本的变更进行有效的控制管理。
ClearCase(CC)
    是ROSE构件的一部分，目前最牛的配置管理工具，主要应用于复杂的产品发放、分布式团队合作、并行的开发和维护任务。可以控制word, excel,powerpoint，visio等文件格式，对于不认识的格式可以自己定义一种类型来标识。
Visual SourceSafe（VSS）
    简单易用、方便高效、与Windows操作系统及微软开发工具高度集成。
CVS（Concurrent Versions System）
    是开发源码的并发版本系统,它是目前最流行的面向软件开发人员的源代码版本管理解决方案。它可用于各种平台，包括 Linux 、Unix和 Windows NT/2000/XP等等。
    前面三种是重量级的商业版本控制工具，更适合庞大的团队和项目，并且价格不菲。Visual SourceSafe是微软的产品，当然只能用在windows平台并与微软的开发工具无缝集成。CVS免费开源，并且几乎所有开源项目都是使用CVS进行版本管理，无疑，它是我们Java开发者最优选择。

CVS的历史、功能、基本概念的介绍

历史
    CVS 诞生于 1986 年，当时作为一组 shell 脚本而出现；1989年3月，Brian Berlinor用C语言重新设计并编写了CVS的代码；1993年前后，Jim Kingdon最终将CVS设计成基于网络的平台，开发者们能从Internet任何地方获得程序源代码。截至目前最新版本是2004年12月13日发布的1.12.11。

功能介绍
一、 代码统一管理，保存所有代码文件更改的历史记录。对代码进行集中统一管理，可以方便查看新增或删除的文件，能够跟踪所有代码改动痕迹。可以随意恢复到以前任意一个历史版本。并避免了因为版本不同引入的深层BUG。
二、 完善的冲突解决方案，可以方便的解决文件冲突问题，而不需要借助其它的文件比较工具和手工的粘贴复制。
三、 代码权限的管理。可以为不同的用户设置不同的权限。可以设置访问用户的密码、只读、修改等权限，而且通过CVS ROOT目录下的脚本，提供了相应功能扩充的接口，不但可以完成精细的权限控制，还能完成更加个性化的功能。
四、 支持方便的版本发布和分支功能。

基本概念
资源库（Repository）
CVS的资源库存储全部的版本控制下的文件copy，通常不容许直接访问，只能通过cvs命令，获得一份本地copy，改动后再check in（commit）回资源库。而资源库通常为与工作目录分离的。CVS通过多种方式访问资源库。每种方法有不同目录表示形式。
版本（Revision）
每一个文件的各个版本都不相同，形如1.1, 1.2.1,一般1.1是该文件的第一个revision，后面的一个将自动增加最右面的一个整数，比如1.2, 1.3, 1.4...有时候会出现1.3.2.2，原因见后。revision总是偶数个数字。一般情况下将revision看作时CVS自己内部的一个编号，而tag则可以标志用户的特定信息。
标签（Tag）
用符号化的表示方法标志文件特定revision的信息。通常不需要对某一个孤立的文件作tag，而是对所有文件同时作一个tag，以后用户可以仅向特定tag的文件提交或者checkout。另外一个作用是在发布软件的时候表示哪些文件及其哪个版本是可用的；各文件不同revision可以包括在一个tag中。如果命名一个已存在的tag默认将不会覆盖原来的；
分支（Branch）
当用户修改一个branch时不会对另外的branch产生任何影响。可以在适当的时候通过合并的方法将两个版本合起来；branch总是在当前revision后面加上一个偶数整数（从2开始，到0结束），所以branch总是奇数个数字，比如1.2后面branch为1.2.2，该分支下revision可能为1.2.2.1,1.2.2.2,...
冲突（Conflct）
完全是纯文本的冲突，不包含逻辑上的矛盾。一般是一份文件，A做了改动，B在A提交之前也做了改动，这样最后谁commit就会出现冲突，需要手工解决冲突再提交。

CVS与eclipse集成开发
  前面对CVS的历史、功能、概论等理论知识做了介绍。下面我们将使用最流行的Java IDE Eclipse中内置的CVS工具，以一个完整开发流程，介绍实际环境中CVS的正确使用。关于CVS系统的安装，不是本文的内容，您可以从附录的链接中获取安装的介绍资料。

常用的CVS控制命令
Check Out（检出）
把源文件从cvs源代码仓库中取出，缺省的版本是最新的版本，你也可以选择指定的版本。在每次更改源代码之前，需要Check Out最新的版本，再起基础之上对源代码进行修改。将代码目录checkout到指定目录下，所有文件都是read-write。
Check In（检入）
把源代码加入到cvs源代码仓库中，每一个添加进代码库中的文件的版本是 1.1。以后每次修改文件重新ci以后，此文件的版本递增为1.2 ，1.3.……。在每次对源代码修改之后，需要Check In，提交最新版本的源代码。
Synchronize with Repository(与资源库同步，简称同步)
使本地更改与资源库同步，它会列出本地和资源库之间不同的所有文件。
Add to Version Control
将新的文件加入到版本控制之中。
Add to .cvsIgnore
将文件设置到版本控制之外，这样该文件或目录中的文件的更改在CVS中不可见，即使同步也无法发现。

CVS正确使用步骤
一、 同步（Synchronize）
就是将本地更改与服务器同步，同步之后可以清晰的看到上一捡出（Check Out）版本之后本地、服务器上的最新改动。这是非常有用的，特别是敏捷开发，强调集体拥有代码。有了同步功能，你可以全局把握项目的代码，可以很方便的跟踪公共模块代码的任何改动。
具体操作：在Eclipse的资源视图（Resource Perspective）或者Java视图（Java Perspective）中，选中要同步的目录，点击右键选择"Synchronize with Repository",之后它将显示同步的视图。如下图：
 
(图一、CVS同步视图)
同步之后，它有四种Mode可以选择，见上图绿色框框里按钮。从做到右分别为：
Incoming Mode：表示修改是来自服务器，对应于更新（update）操作。
Outgoing Mode：表示修改是来自本地，对应提交（commit）操作。
Incoming/ Outgoing Mode：本地和服务器修改都在该模式（Mode）中显示。
Conflicts Mode：显示本地和服务器修改的冲突文件。
二、 更新（update）
比较简单，选择Incoming Mode，再选中要更新的文件，右键选择update操作。
三、 解决冲突并合并(solve conflct and merge)
如果有冲突文件，冲突文件不能更新。你必须先解决冲突再操作。选中冲突的文件，再点右键选择"Open in Compare Editor"，用比较工具打开该文件。如下图：

（图二、CVS比较器视图）

比较器（Compare）视图，左边版本底的是本地文件（Local File），右边是远程服务器文件（Remote File）。使用"Select Next Change"按钮（绿框中的第一箭头向下按钮），逐一查看不同点。如果不同点标识为黑色框框，则不用管它。如果是蓝色框框，则需要手工调整。如上图，不同点是蓝色框框，将鼠标放到两个不同点的中间小方框中，则凸出一个向右的按钮，并显示提示信息"Copy Current Change from Right to Left"，意思是将右边服务器的不同点覆盖到左边的本地文件。点中此按钮。重复这样的操作，将所有服务器上的更改拷贝到本地。
如果有一行代码，本地和服务器都同时做了修改。这时，修改点则显示红色框框。这时，你就必须手工做正确的修改。全部修改完成，保存本地文件。
此时，如果修改点没有了蓝色的框框，就可以开始做合并（merge）操作了。操作也很简单，选择该文件，点击右键，选择"Mark as merged"。
注意：必须确保没有蓝色框框，即完全拷贝了服务器的修改才可以做合并（merge）操作，否则会覆盖服务器上的代码。
四、 提交（commit）
更新服务器代码，解决冲突之后，首先要查看本地文件修改之后是否有错误。如果有，当然首先解决错误，再提交。

附录：
http://www.8848software.com/scmchina/scmtools.htm 由很多版本控制工具的文档链接。
http://www.perforce.com/perforce/reviews.html Infrastructure Group对Perforce 和Clearcase, CVS, PVCS,Visual SourceSafe (VSS)几种CM工具进行了定量和定性的比较. 对于定性的比较，内容涉及工具支持的方法和环境；对于定量的比较，包括在不同的项目规模上，执行不同的活动所需要的时间。

一个比较最大值的函数
  我们首先引入一个比较最大值的函数。我们传入一个类型为int的数组参数，它将返回最大值的那个元素。代码如下：
public class Largest {
 public static int largest(int[] datas){
  int max = 0;
  
  for(int i = 0 ; i < datas.length ; i++){
   if(max < datas[i]){
    max = datas[i];
   }
  }
  return max;
 }
}
  可是，如何写我们的测试代码呢？

直接在Largest类中添加一个main方法，要么重新写一个可运行的类来测试Largest。这样的测试，同样给我们带来了很大的挑战：
1、 验证困难。如何去验证代码的行为和我们的期望一致呢？使用很多的if…else再加上＝＝或equals()来判断？对异常的情况又如何处理呢？混乱的验证，很容易给我们的测试代码带来BUG，让我们对自己的测试不够自信。
2、 测试类无法管理。我们如何直观的得到测试运行成功或失败的消息?用原始的System.out.println()吗？我们能一次运行多个单元测试吗？如果前面的测试运行出现异常，后面的测试还能继续运行吗？如果测试类很多，上百个甚至更多，我们能方便的由控制台输出测试结果吗？
3、 无法统计测试代码覆盖情况。缺少统一的测试代码编写规范和约定，可读性和维护性差。
不过，面对这些挑战不用沮丧。单元测试框架已经帮我们解决了这些问题，它提供了很多测试的基础设施，让我们能把更多的经历投入到测试代码的编写中来。

JUnit
JUnit最初是由Erich Gamma（GoF之一）和Kent Beck（xp和refactor的先驱之一）编写的，它是一个开源的Java测试框架，用于编写和运行可重复的测试。

下面我们逐步介绍如何对Largest类测试：
一、 JUnit的安装。如果你使用的开发工具是Eclipse，不用做任何安装，它已经提供了Junit的支持。否则，你需要去http://www.junit.org/ 下载Junit安装包。安装非常简单，只要将junit.jar包设置到ClassPath中，让你的Java代码能够找到它就可以了。
二、 编写测试代码。代码如下：
    public class LargestTest extends TestCase {
  public void testLargest(){
   int[] datas = {7,8,9};
   assertEquals(9,Largest.largest(datas));
  }
}
说明：
1、 测试类一般要继承抽象类TestCase。它实现了各种测试方法，并提供了一个测试过程的架构。
2、 测试代码通过断言（Assert）来判断某个被测试函数是否正常工作。JUnit提供了很多断言函数，用来确定：某个条件是否为真；两个数据是否相等，或者不等，或者其它的一些情况。
3、 测试方法名以“test”开头，这样JUnit框架会自动发现这是一个测试方法。

三、 运行测试类。
   运行测试成功。

我们的单元测试这样就算完成了吗？不，上面的测试只能算是一次验证而已。我们给的数据中，最大值9是数组的最后一个元素，如果9是第一个元素它还正确吗？如果数据是负数呢？等等。我们的求最大值函数有着很多的边界情况需要单元测试来验证。
   因此，我们在写单元测试之前，一定要对测试做一个周全的计划，预先设置好要测试的内容，可能发生错误的边界条件。
下面是对Largest做的测试计划：
1、 数组元素的位置是否对最大值产生影响？
l [7,8,9] – 9
l [7,9,8] – 9
l [9,8,7] – 9
2、 如果有两个相等的最大值，会出现什么情况呢？
l [7,9,8,9] – 9
3、如果数组中只有一个元素，结果会怎么样？
l [1] - 1
4、 如果元素都是负数呢？
l [-7,-8,-9] - -7
完整的测试代码应该如下：
public class LargestTest extends TestCase {
 
 public void testSimple(){
  assertEquals(9,Largest.largest(new int[]{7,8,9}));
 }
 public void testOrder(){
  assertEquals(9,Largest.largest(new int[]{7,9,8}));
  assertEquals(9,Largest.largest(new int[]{9,8,7}));
 }
 public void testDups(){
  assertEquals(9,Largest.largest(new int[]{7,9,8,9}));
 }
 public void testOne(){
  assertEquals(1,Largest.largest(new int[]{1}));
 }
 public void testNegative(){
   assertEquals(-7,Largest.largest(new int[]{-7,-8,-9}));
 }
}
当然，你可以写完一个测试方法就立即来运行它。这次并没有那么幸运了，在运行最后一个测试方法testNegative()时出现了错误：
junit.framework.AssertionFailedError: expected:<-7> but was:<0>
 at test.junit.LargestTest.testNegative(LargestTest.java:24)
细心的你，也许在一开始就发现了Largest的这个Bug。原来我们的字段max初始化为0是不对的，应该改为Integer.MIN_VALUE。
由此我们可以想到，使用单元测试确实可以尽早的发现隐藏的BUG，上一篇我们也说过，越早发现BUG就能节省更多的时间，降低更多的风险。
这是，我们的单元测试已经完美结束了吗？呵呵，也许你会想到，如果在largest()方法中传入数组为空，又会怎么样呢？这个问题留给我们的读者思考吧。

写到这里，算是入门结束了吧！关于JUnit的详细介绍，网上有非常多的文章，去google你可以找到一大堆。下面我提供几个不错的单元测试网站，希望能对你有所帮助：
51Testing-无忧软件测试网：http://www.51testing.com/
测试时代：http://www.testage.net/
UML软件工程组织－软件测试：http://www.uml.org.cn/Test/test.asp
测试管理中心：http://www.testmanager.com.cn/
软件工程专家网：http://www.51cmm.com/
开放软件测试研究：http://www.opentest.net/

        测试是软件开发的重要环节之一。按照软件开发的过程测试可分为：单元测试、集成测试、系统测试、域测试（Field test）等。我们这里将讨论面向程序员的单元测试。本文首先介绍单元测试的定义，为什么要使用单元测试？单元测试能给我们带来的好处。之后我们将介绍单元测试的范畴，最后将讨论很多朋友不写单元测试的借口。希望本文能够再次引起您对单元测试的重视，并说服您老板对编写单元测试的支持，能让美丽的单元测试真正应用到您的项目之中。

什么是单元测试
      单元测试是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。例如，你可能把一个很大的值放入一个有序list 中去，然后确认该值出现在list 的尾部。或者，你可能会从字符串中删除匹配某种模式的字符，然后确认字符串确实不再包含这些字符了。
    单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。

为什么要使用单元测试
    我们编写代码时，一定会反复调试保证它能够编译通过。如果是编译没有通过的代码，没有任何人会愿意交付给自己的老板。但代码通过编译，只是说明了它的语法正确；我们却无法保证它的语义也一定正确，没有任何人可以轻易承诺这段代码的行为一定是正确的。
    幸运，单元测试会为我们的承诺做保证。编写单元测试就是用来验证这段代码的行为是否与我们期望的一致。有了单元测试，我们可以自信的交付自己的代码，而没有任何的后顾之忧。

单元测试有下面的这些优点：
1、它是一种验证行为。
    程序中的每一项功能都是测试来验证它的正确性。它为以后的开发提供支缓。就算是开发后期，我们也可以轻松的增加功能或更改程序结构，而不用担心这个过程中会破坏重要的东西。而且它为代码的重构提供了保障。这样，我们就可以更自由的对程序进行改进。
2、它是一种设计行为。
    编写单元测试将使我们从调用者观察、思考。特别是先写测试（test-first），迫使我们把程序设计成易于调用和可测试的，即迫使我们解除软件中的耦合。
3、它是一种编写文档的行为。
    单元测试是一种无价的文档，它是展示函数或类如何使用的最佳文档。这份文档是可编译、可运行的，并且它保持最新，永远与代码同步。
4、它具有回归性。
    自动化的单元测试避免了代码出现回归，编写完成之后，可以随时随地的快速运行测试。

单元测试的范畴
    如果要给单元测试定义一个明确的范畴，指出哪些功能是属于单元测试，这似乎很难。但下面讨论的四个问题，基本上可以说明单元测试的范畴，单元测试所要做的工作。
1、 它的行为和我期望的一致吗？
    这是单元测试最根本的目的，我们就是用单元测试的代码来证明它所做的就是我们所期望的。
2、 它的行为一直和我期望的一致吗？
    编写单元测试，如果只测试代码的一条正确路径，让它正确走一遍，并不算是真正的完成。软件开发是一个项复杂的工程，在测试某段代码的行为是否和你的期望一致时，你需要确认：在任何情况下，这段代码是否都和你的期望一致；譬如参数很可疑、硬盘没有剩余空间、缓冲区溢出、网络掉线的时候。
3、 我可以依赖单元测试吗？
   不能依赖的代码是没有多大用处的。既然单元测试是用来保证代码的正确性，那么单元测试也一定要值得依赖。
4、 单元测试说明我的意图了吗？
    单元测试能够帮我们充分了解代码的用法，从效果上而言，单元测试就像是能执行的文档，说明了在你用各种条件调用代码时，你所能期望这段代码完成的功能。

不写测试的借口
    到这里，我们已经列举了使用单元测试的种种理由。也许，每个人都同意，是的，该做更多的测试。这种人人同意的事情还多着呢，是的，该多吃蔬菜，该戒烟，该多休息，该多锻炼……这并不意味着我们中的所有人都会这么去做，不是吗？
1、 编写单元测试太花时间了。
    我们知道，在开发时越早发现BUG，就能节省更多的时间，降低更多的风险。
    下图表摘自<<实用软件度量>>(Capers Jones，McGraw-Hill 1991)，它列出了准备测试，执行测试，和修改缺陷所花费的时间(以一个功能点为基准)，这些数据显示单元测试的成本效率大约是集成测试的两倍，是系统测试的三倍(参见条形图)。
 
    术语：域测试(Field test)意思是在软件投入使用以后，针对某个领域所作的所有测试活动。
    如果你仍然认为在编写产品代码的时候，还是没有时间编写测试代码，那么请先考虑下面这些问题：
        1）、对于所编写的代码，你在调试上面花了多少时间。
        2）、对于以前你自认为正确的代码，而实际上这些代码却存在重大的bug，你花了多少时间在重新确认这些代码上面。
        3）、对于一个别人报告的bug，你花了多少时间才找出导致这个bug 的源码位置。
    回答完这些问题，你一定不再以“太花时间”作为拒绝单元测试的借口。
2、 运行测试的时间太长了。
    合适的测试是不会让这种情况发生的。实际上，大多数测试的执行都是非常快的，因此你在几秒之内就可以运行成千上万个测试。但是有时某些测试会花费很长的时间。这时，需要把这些耗时的测试和其他测试分开。通常可以每天运行这种测试一次，或者几天一次。
3、 测试代码并不是我的工作。
    你的工作就是保证代码能够正确的完成你的行为，恰恰相反，测试代码正是你不可缺少的工作。
4、 我并不清楚代码的行为，所以也就无从测试。
   如果你实在不清楚代码的行为，那么估计现在并不是编码的时候。如果你并不知道代码的行为，那么你又如何知道你编写的代码是正确的呢?
5、 但是这些代码都能够编译通过。
    我们前面已经说过，代码通过编译只是验证它的语法通过。但并不能保证它的行为就一定正确。
6、 公司请我来是为了写代码，而不是写测试。
    公司付给你薪水是为了让你编写产品代码，而单元测试大体上是一个工具，是一个和编辑器、开发环境、编译器等处于同一位置的工具。
7、 如果我让测试员或者QA（Quality Assurance）人员没有工作，那么我会觉得很内疚。
   你并不需要担心这些。请记住，我们在此只是谈论单元测试，而它只是一种针对源码的、低层次的，为程序员而设计的测试。在整个项目中，还有其他的很多测试需要这些人来完成，如：功能测试、验收测试、性能测试、环境测试、有效性测试、正确性测试、正规分析等等。
8、 我的公司并不会让我在真实系统中运行单元测试。
    我们所讨论的只是针对开发者的单元测试。也就是说，如果你可以在其他的环境下（例如在正式的产品系统中）运行这些测试的话，那么它们就不再是单元测试，而是其他类型的测试了。实际上，你可以在你的本机运行单元测试，使用你自己的数据库，或者使用mock 对象。

总结
  总而言之，单元测试会让我们的开发工作变得更加轻松，让我们对自己的代码更加自信。无论是大型项目还是小型项目，无论是时间紧迫的项目还是时间宽裕的项目，只要代码不是一次写完永不改动，编写单元测试就一定超值，它已成为我们编码不可缺少的一部分。

参考资料
《单元测试之道Java版——使用JUNIT》：这是一本非常好的介绍单元测试的书，作者讲的非常透彻，译者的文笔也很好。在此向您强烈推荐。本文内容，也有很多直接引用于此书！
《JUNIT IN ACTION》：这是一本专门介绍JUNIT的好书。

1、概述
　　Junit测试是程序员测试，即所谓白盒测试，因为程序员知道被测试的软件如何（How）完成功能和完成什么样（What）的功能。
　　Junit本质上是一套框架，即开发者制定了一套条条框框，遵循这此条条框框要求编写测试代码，如继承某个类，实现某个接口，就可以用Junit进行自动测试了。
　　由于Junit相对独立于所编写的代码，可以测试代码的编写可以先于实现代码的编写，XP 中推崇的 test first design的实现有了现成的手段：用Junit写测试代码，写实现代码，运行测试，测试失败，修改实现代码，再运行测试，直到测试成功。以后对代码的修改和优化，运行测试成功，则修改成功。
　　Java 下的 team 开发，采用 cvs(版本控制) + ant(项目管理) + junit(集成测试) 的模式时，通过对ant的配置，可以很简单地实现测试自动化。

　　对不同性质的被测对象，如Class，Jsp，Servlet，Ejb等，Junit有不同的使用技巧，以后慢慢地分别讲叙。以下以Class测试为例讲解，除非特殊说明。

2、下载安装

• 去Junit主页下载最新版本3.8.1程序包junit-3.8.1.zip
  
• 用winzip或unzip将junit-3.8.1.zip解压缩到某一目录名为$JUNITHOME
  
• 将junit.jar和$JUNITHOME/junit加入到CLASSPATH中，加入后者只因为测试例程在那个目录下。
  
• 注意不要将junit.jar放在jdk的extension目录下
  
• 运行命令,结果如右图。
  java junit.swingui.TestRunner junit.samples.AllTests

3、Junit架构
　　下面以Money这个类为例进行说明。

• 命令模式
  　　利用TestCase定义一个子类，在这个子类中生成一个被测试的对象，编写代码检测某个方法被调用后对象的状态与预期的状态是否一致，进而断言程序代码有没有bug。
  　　当这个子类要测试不只一个方法的实现代码时，可以先建立测试基础，让这些测试在同一个基础上运行，一方面可以减少每个测试的初始化，而且可以测试这些不同方法之间的联系。
  　　例如，我们要测试Money的Add方法，可以如下:
  public class MoneyTest extends TestCase { //TestCase的子类
      public void testAdd() { //把测试代码放在testAdd中
          Money m12CHF= new Money(12, "CHF");  //本行和下一行进行一些初始化
          Money m14CHF= new Money(14, "CHF");        
          Money expected= new Money(26, "CHF");//预期的结果
          Money result= m12CHF.add(m14CHF);    //运行被测试的方法
          Assert.assertTrue(expected.equals(result));     //判断运行结果是否与预期的相同
      }
  }
  
  　　如果测试一下equals方法，用类似的代码，如下：
  public class MoneyTest extends TestCase { //TestCase的子类
      public void testEquals() { //把测试代码放在testEquals中
          Money m12CHF= new Money(12, "CHF"); //本行和下一行进行一些初始化
          Money m14CHF= new Money(14, "CHF");

          Assert.assertTrue(!m12CHF.equals(null));//进行不同情况的测试
          Assert.assertEquals(m12CHF, m12CHF);
          Assert.assertEquals(m12CHF, new Money(12, "CHF")); // (1)
          Assert.assertTrue(!m12CHF.equals(m14CHF));
      }
  }

  
  　　当要同时进行测试Add和equals方法时，可以将它们的各自的初始化工作，合并到一起进行，形成测试基础,用setUp初始化，用tearDown清除。如下：
  public class MoneyTest extends TestCase {//TestCase的子类
      private Money f12CHF;//提取公用的对象
      private Money f14CHF;   

      protected void setUp() {//初始化公用对象
          f12CHF= new Money(12, "CHF");
          f14CHF= new Money(14, "CHF");
      }
      public void testEquals() {//测试equals方法的正确性
          Assert.assertTrue(!f12CHF.equals(null));
          Assert.assertEquals(f12CHF, f12CHF);
          Assert.assertEquals(f12CHF, new Money(12, "CHF"));
          Assert.assertTrue(!f12CHF.equals(f14CHF));
      }
      
      public void testSimpleAdd() {//测试add方法的正确性
          Money expected= new Money(26, "CHF");
          Money result= f12CHF.add(f14CHF);
          Assert.assertTrue(expected.equals(result));
      }
  }

  
  　　将以上三个中的任一个TestCase子类代码保存到名为MoneyTest.java的文件里，并在文件首行增加
  import junit.framework.*;
  ，都是可以运行的。关于Junit运行的问题很有意思，下面单独说明。
  　　上面为解释概念“测试基础(fixture)”，引入了两个对两个方法的测试。命令模式与集成模式的本质区别是，前者一次只运行一个测试。
  
• 集成模式
  　　利用TestSuite可以将一个TestCase子类中所有test***()方法包含进来一起运行，还可将TestSuite子类也包含进来，从而行成了一种等级关系。可以把TestSuite视为一个容器，可以盛放TestCase中的test***()方法，它自己也可以嵌套。这种体系架构，非常类似于现实中程序一步步开发一步步集成的现况。
  　　对上面的例子，有代码如下：
  public class MoneyTest extends TestCase {//TestCase的子类
      ....
      public static Test suite() {//静态Test
          TestSuite suite= new TestSuite();//生成一个TestSuite
          suite.addTest(new MoneyTest("testEquals")); //加入测试方法
          suite.addTest(new MoneyTest("testSimpleAdd"));
          return suite;
      }
  }
  
  　　从Junit2.0开始，有列简捷的方法:
  public class MoneyTest extends TestCase {//TestCase的子类
      ....
      public static Test suite() {静态Test
          return new TestSuite(MoneyTest.class); //以类为参数
      }
  }
  
  　　TestSuite见嵌套的例子，在后面应用案例中有。
  　　

4、测试代码的运行
　　先说最常用的集成模式。
　　测试代码写好以后，可以相应的类中写main方法，用java命令直接运行；也可以不写main方法，用Junit提供的运行器运行。Junit提供了textui,awtui和swingui三种运行器。
　　以前面第2步中的AllTests运行为例，可有四种：

• 静态方法
  
  TestCase test= new MoneyTest("simple add") {
  public void runTest() {
  testSimpleAdd();
  }
  };
  
  
• 动态方法
  
  TestCase test= new MoneyTest("testSimpleAdd");

5、应用案例

1. Junit Primer例程，运行如下：
   java com.hedong.JunitLearning.Primer.ShoppingCartTest
   
   
2. Ant+Junit+Mailto实现自动编译、调试并发送结果的build.xml
   
3. JUnit实施,写得很棒，理解也深刻。例程运行如下：
   java com.hedong.JunitLearning.car.testCarNoJunit
   java junit.swingui.TestRunner com.hedong.JunitLearning.car.testCar
   
   
4. Junit与log4j结合，阿菜的例程运行：
   cd acai
   ant junit
   
   
5. 
   
6. 
   
7. 
   
8. 
   

1. 不要用TestCase的构造函数初始化Fixture，而要用setUp()和tearDown()方法。
   
2. 不要依赖或假定测试运行的顺序，因为JUnit利用Vector保存测试方法。所以不同的平台会按不同的顺序从Vector中取出测试方法。不知3.8中是不是还是如此，不过它提供的例子有一个是指定用VectorSuite的，如果不指定呢？
   
3. 避免编写有副作用的TestCase。例如：如果随后的测试依赖于某些特定的交易数据，就不要提交交易数据。简单的回滚就可以了。
   
4. 当继承一个测试类时，记得调用父类的setUp()和tearDown()方法。
   
5. 将测试代码和工作代码放在一起，一边同步编译和更新。（使用Ant中有支持junit的task.）
   
6. 测试类和测试方法应该有一致的命名方案。如在工作类名前加上test从而形成测试类名。
   
7. 确保测试与时间无关，不要依赖使用过期的数据进行测试。导致在随后的维护过程中很难重现测试。
   
8. 如果你编写的软件面向国际市场，编写测试时要考虑国际化的因素。不要仅用母语的Locale进行测试。
   
9. 尽可能地利用JUnit提供地assert/fail方法以及异常处理的方法，可以使代码更为简洁。
   
10. 测试要尽可能地小，执行速度快。
    
11. 把测试程序建立在与被测对象相同的包中
    
12. 在你的原始代码目录中避免测试码出现，可在一个源码镜像目录中放测试码
    
13. 在自己的应用程序包中包含一个TestSuite测试类
    
14. 
    

1. 可运行例程.jar
   
2. Build.xml
   
3. 阿菜的例程
   
4. Junit API 汉译(pdf)
   

8、未完成的任务

1. httpunit
   
2. cactus
   
3. 将Junit用链接池测试
   

1. JUnit入門
   http://www.dotspace.twmail.org/Test/JUnit_Primer.htm
   
2. 怎样使用Junit Framework进行单元测试的编写
   http://www.chinaunix.net/bbsjh/14/546.html
   
3. Ant+Junit+Log4J+CVS进行XP模式开发的建立
   http://ejb.cn/modules/tutorials/printpage.php?tid=4
   
4. 用HttpUnit测试Web应用程序
   http://www.zdnet.com.cn/developer/code/story/0,2000081534,39033726,00.htm
   
5. 有没有用过Cactus的，Web层的测试是Cactus还是JUnit？
   http://www.jdon.com/jive/thread.jsp?forum=16&thread=9156
   
6. Ant+junit的测试自动化 biggie（原作）
   http://www.csdn.net/Develop/article/19%5C19748.shtm
   
7. JUnit实施
   http://www.neweasier.com/article/2002-08-07/1028723459.html
   
8. JUnitTest Infected: Programmers Love Writing Tests
   http://junit.sourceforge.net/doc/testinfected/testing.htm
   
9. JUnit Cookbook
   http://junit.sourceforge.net/doc/cookbook/cookbook.htm
   
10. JUnit Primer
    http://www.itu.dk/~lthorup/JUnitPrimer.html
    
11. IBM DevelopWorks
    http://www-106.ibm.com/search/searchResults.jsp?query=junit&searchScope=dW&searchType=1&searchSite=dWChina&pageLang=zh&langEncoding=gb2312&Search.x=0&Search.y=0&Search=Search