下面我按照我们的分层架构来说说我们的分层测试，看到这里也有讨论DAO测试的，讨论分层测试的，不过很多帖子都已经不能回复了。
为什么要写这篇文章
想总结一下我们的TDD作法。正在看《JUnit in Action》，从中得到了不少经验和做事情的正确方法，并不断地修正了自己的一些错误的做法。某些问题我想知道大家的解决方案，看看大家有什么好的或者成熟的方案。
领域层
起初我们使用TDD的时候，从领域模型开始，两个人先在纸上画出领域模型的草图，写上一些显而易见的方法，然后打开Eclipse开始写JUnit单元测试，Eclipse对于TDD的支持很好，我们按照特性描述（就算是User Story吧），开始创建每个对象，当然会抱错，然后使用Eclipse自动创建那个类，我们会根据需求加入责任，然后自动生成method stub。我们花了两个小时创建了6个对象，完成了一个特性。当然，对于领域层的测试，这一切都很正常。
然后我们引入了Springframework，我们先设计一些接口，然后在Spring的配置文件中映射好实现这些接口的对象，然后我们在测试用例中写上spring初始化bean的代码：
我们在每一个测试方法里都写，后来知道应该把这样的代码放到setUp中。我又开始使用Spring的测试框架，但是这样运行单元测试实在是太慢了！后来，知道了测试领域层的时候不要混入框架，创建对象直接用new就好。
表现层
我来继续观察表现层，其中包括Struts Action作为控制器的控制层，和Ext+HTML的UI。UI已经是一个独立的“系统”了，唯一和它联系的就是Action了。Action的作用是接收Http Request，读取参数，调用业务门面，拼接并返回Ext需要读取的数据源（XML或JSon）。我们采取的Struts和Spring的整合策略是将Action托管给Spring。这样，如果想要测试Action：
1、和Spring框架一起来测试
2、Action中的逻辑很简单，（其实Facade中封装了领域对象的协作，也可看作一种控制器）测试的目的是：
1）看看参数传过来没有
2）领域模型是不是返回了正确的值
3）XML或JSon的返回串拼接的是否正确。
4）还有更基础的是测试一下Struts和Spring的配置文件写的对不对。
3、实际上返回的领域对象只是Mock Object。
我们的测试很原始，还没有使用过StrutsActionTest这样的框架，只是直接使用Tomcat来测试（不过已经比直接使用WebLogic容易多了）。
速度很慢，每次都要初始化那些XML配置文件，而且还要读根本用不上的Hibernate的配置文件。
关于Hibernate配置文件的问题是这样的：
我们不得不在进行DAO测试时，使用没有注释掉的value来读取cfg.xml。而在测试Action时，又需要使用注释掉的配置。
我觉得或许采用下面的策略能好些，不过不知道各位在自己的项目中都是如何做的：
测试表现层时用专为测试这一层的Spring配置文件（我们采用了org.springframework.web.context.ContextLoaderListener这种方式），避免和Hibernate配置文件挂上联系。
持久层
采用DAO模式，我们的DAO很简单，就是直接调用Spring的getHibernateTemplate的方法，于是测试的时候关键就是测试：
1、HQL语句是否书写正确，SQL语句是否生成正确
2、Hibernate映射是否写的正确
3、Sping和Hibernate基础设施是否配置正确
4、是否按照预期完成CRUD操作。
测试一个DAO需要耗时2秒，而不是0.12秒。不过如果基于上面的目的进行测试也无可厚非。
单元测试真的是这样做的吗？
按《JUnit in Action》上的说法，单元测试还包括集成单元测试，功能单元测试。
所以看上去，在DAO层和控制层测试时是绑定了框架一起进行测试是有道理的，可以称之为集成单元测试。那么我还是有以下疑问：
1、这样做是正确的吗？大家都是怎么做的？
2、持续集成中运行单元测试包不包括这部分集成单元测试呢？还是仅包含测试业务逻辑的领域层测试
3、对于报表驱动的业务系统（类似于Kent他们第一次使用XP时做的那个系统），这样做正确吗？不过我们的业务也很复杂。
