从第一次知道Fitnesse这个集成测试工具到现在也已经差不多有2年多的时间了。在这个期间把Fitnesse的源码也算是反反复复阅读了很多遍，算是对其实现的原理和方法有所了解。在最近一次对Fitnesse最新版本代码的研究中我发现，Fitnesse除了是一个很好的开源集成测试框架之外，它的源代码还是一个非常好的实施Java单元测试的例好例子。
首先我们可以看到在Fitnesse的每个类，都有一个对应的Test的类来构建针对这个功能类的单元测试。
一个好的单元测试的命名是非常重要的，它可以让我们很清楚的指导我们的单元测试类是针对哪个功能类编写的。Fitnesse的开发团队采用的命名规范是在功能类的名字后面增加Test的后缀，这样可以在一个包里面很好的区分功能类和测试类。
单元测试类和源码之间的放置关系也是我们经常遇到的问题。在这里Fitnesse的开发团队把所有的单元测试类（*.Test）和源码是放在同一个项目里面，并且也放在同一个包内，这样在功能上非常容易区分和归类。我们可以很容易的找到单元类的测试类在哪里。其次这样的单元测试类在编写上更加方便，不太收到java的access控制的影响。例如protected的变量在包内是可见的，这样的话同一包内的单元测试类就可以对很轻松的针对它进行单元测试。第三在Fitnesse的发布的build.xml中，也很好的继承了单元测试，这样在发布的过程中对于质量有了很好的控制，做到了单元测试自动化。参考下面的build.xml文件
我们到底应该对哪些方法做单元测试呢？这个问题也一直是我们在做单元测试的时候一直困扰的问题。我们之前习惯上算是针对没一个方法构建单元测试，这样的单元测试在覆盖率上很高，但是工作的时间成本就会直线上身。测试工作需要在时间和质量上寻找一个平衡。从Fitnesse的源代码中可以看到，Fitnesse的开发团队并没有采用上面的那种单元测试的方法。他们采用的是针对主要的功能方法进行单元测试。我们来看下面这个例子
……………………
查看全文请点击下载：http://www.51testing.com/html/13/n-241113.html
这样就完成了针对所有可能的Http Response Code的测试的覆盖。这里只是一个简单的Fitnesse中的例子，在很多其他的单元测试类中我们都能看到。
针对主要功能函数的构建单元测试对于独立进行单元测试的测试团队来说是一个很大的考验。正式因为Fitnesse源码的单元测试是其开发团队自己编写的，他们可以很清楚的指导哪个函数是关键函数，哪个是不重要的。但是如果是独立的测试团队，他们就很难去判断被测试函数的重要性来决定是否需要构建单元测试。
单元测试中最最重要的一个概念就是驱动模块和桩模块。从百度百科上我查到的定义如下：
驱动模块是用来模拟被测试模块的上一级模块，相当于被测模块的主程序。它接收数据，将相关数据传送给被测模块，启用被测模块，并打印出相应的结果。
