为什么要写这篇文章

　　想总结一下我们的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的配置文件。