1. 资料
2. 选型
2.1 JUnit 3.8 vs JUnit 4.5
JUnit 4.0打破了原来的继承体系，纯以annotation标注。但觉得其实像JUnit 3.8那样约定大于配置也没什么不好的，大家按命名规则也没什么不好，也不用去import static xxx.Assert.* 了。而且Spring也为Junit 3提供了JUnit4作为重要特性的@IfProfileValue(符合条件才运行),@ExpectedException(期望异常),@Timed(超时控制)。
所以最后还是坚持JUnit 3.8，并关注JUnit 4.x 以后会不会有突飞猛进的发展。
2.2 EasyMock vs JMock
经过比较觉得其实EasyMock要好用一些。
2.3 其他
- Web Service集成测试工具，SoapUI挺好用的，特别是Pro版的试用版，可以与不会编码的测试人员共用同一个工具。
- Web集成测试工具，Selenium
。
- 测试代码覆盖率工具，国内现状，普通项目的测试用例暂时还没奢侈到能检查覆盖率的地步。
- 压力测试工具，貌似客户一般只认LoadRunner的结果，其他的开源工具结果都不怎么招人待见。
3. in SpringSide 3.0
测试用例分三类：
一类是单元测试，使用JUnit 3.8+ EasyMock，Mock掉所有依赖类，严格隔绝其他类对本类的影响。
二类是集成测试，使用JUnit 3.8+ Spring的TestContext Framework，注入其他依赖Bean，使用实际数据库进行测试。
三类是功能测试，依照测试用例文档，使用SoapUI，Selenium这些外部工具或者纯手工进行测试。
上述三类测试，对问题的定位越来越笼统，但对产品最后质量的测试效率则越来越高。在国内现状中，大力提倡TDD的同时，还不可能严格要求大家必须编写足够的测试用例，愿意写测试的同志已经是好同志了。
3.1 功能测试
测试组的同事作为最后防线，必须编写完整的测试用例文档，覆盖大部分的正常或异常情况，并用SoapUI,Selenium 或手工进行严格的测试。
如果开发组与测试组能共享SoapUI，Selenium工件，那就是最高效的。
在mini-service示例的src/test/soapUI 目录中附带了SoapUI的项目文件。
3.2 集成测试
集成测试会依赖其他的依赖类，不能单独测试。但优点是不用写太多的Mock语句，也能测试几个类集成起来的效果，所以测试效率也会比较高。
Spring 2.5的依赖测试用例支持ApplicationContext依赖注入，事务自动回滚等功能，而且Spring 2.5提供了新的TestContext Framework 详见Spring 2.5 集成测试资料。
因为Spring的类名一贯清晰但超长，所以抽取了SpringTestCase 和 SpringTranscationTestCase两个基类，都默认载入了/applicationContext.xml。
在子类定义更多的applicationContext-*.xml文件时，SpringTestCase基类类定义的applicationContext.xml 会被默认继承。
SpringTranscationTestCase还提供了一个flush()函数，因为Hibernate只有事务提交时才会执行SQL，为了验证你的ORM正确性，必须常常执行flush强制hibernate执行SQL。不过只要不执行提交,sql执行的结果不会影响测试数据库的实际数据。
在mini-service/mini-web层的Service层都使用了集成测试用例。
因为集成测试依赖于真实的数据库等环境，因此希望在测试阶段不默认运行它们。在maven的parent的pom.xml中，定义了surefire插件，在test阶段并不执行package名里含integration的用例。在integration-test阶段才去会执行。也就是在执行mvn integration-test 或mvn deploy,mvn install 时才会执行这些测试。
3.3 单元测试
真正的单元测试，离不开EasyMock了，需要注意的是EasyMock早不需要基于接口，可以直接用cglib对类进行代理。
在mini-service中，有这样一个"真正"单元测试的例子。
