当单元测试遇到框架(转：来自javaeye 作者：sslaowan)

下面我按照我们的分层架构来说说我们的分层测试，看到这里也有讨论DAO测试的，讨论分层测试的，不过很多帖子都已经不能回复了。

为什么要写这篇文章

        想总结一下我们的TDD作法。正在看《JUnit in Action》，从中得到了不少经验和做事情的正确方法，并不断地修正了自己的一些错误的做法。某些问题我想知道大家的解决方案，看看大家有什么好的或者成熟的方案。

领域层 

      起初我们使用TDD的时候，从领域模型开始，两个人先在纸上画出领域模型的草图，写上一些显而易见的方法，然后打开Eclipse开始写JUnit单元测试，Eclipse对于TDD的支持很好，我们按照特性描述（就算是User Story吧），开始创建每个对象，当然会抱错，然后使用Eclipse自动创建那个类，我们会根据需求加入责任，然后自动生成method stub。我们花了两个小时创建了6个对象，完成了一个特性。当然，对于领域层的测试，这一切都很正常。

      然后我们引入了Springframework，我们先设计一些接口，然后在Spring的配置文件中映射好实现这些接口的对象，然后我们在测试用例中写上spring初始化bean的代码：

   

java 代码

1. ApplicationContext ctx = new ClassPathXmlApplicationContext( new                   String[] { "applicationContext.xml" });   
2. service=(BussinessFacade) ctx.getBean("service");  

 

          我们在每一个测试方法里都写，后来知道应该把这样的代码放到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配置文件的问题是这样的：

 

xml 代码

1. <bean id="sessionFactory"  
2.     class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">  
3.     <property name="configLocation">  
4.         <!-- <value>WEB-INF/classes/Account-Hibernate.cfg.xml</value>-->  
5.           <value>Account-Hibernate.cfg.xml</value>    
6.     </property>  
7. </bean>  

       我们不得不在进行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时做的那个系统），这样做正确吗？不过我们的业务也很复杂。