吹弹得破是重回一人犯错，全家光荣的老路

"每个人必须每个unit自己testt通过，每次commit之前必须进行smoke test，每次update下来做一次smoke test，这是必须做的事情，没有什么好打折扣的。

在时间比较短的时候，可以跑所有的测试(smoke test = all tests)，如果项目进行到一定的程度,smoke test可以是容器的加载、数据库sessionFactory生成等等一些最重要的全局性相关的测试"

不管你如何test 依然无法将开发人员完全隔离开 他们的类彼此倚赖 数据彼此穿插 这是什么管理方式都无法回避的.

真正的功能测试和性能测试是需要运行容器 访问数据库的 而不是紧紧做单元测试. 

真正的模块化 每个模块都是独立运行的 因此可以独立测试 独立开发. 这些你用现有的mvc根本做不到. 对java 对类吃的再透也没有用.

这和管理和水平关系都不大，只是习惯而已。


另外不太理解你在想说明什么，单元测试只是开发人员需要编写的测试中最基本的部分，如同你编写一个Java程序必须写一个一个Java类一样

每一种测试承担不同的职责

程序员为什么要分开，绑得越紧越好

模块化中的模块也是要测试的

我是针对楼主的问题谈的 而非单元测试.

I 服了 U !!!

我觉得你真的有点祥林嫂的感觉，言必称xmldb，逢贴必扯xmldb

这个问题，真的是没有结论的
不同项目，不同团队，还有不同公司的管理考评制度导致采用的手段都是不一样的。。

没什么奇怪的 编程必须用到嘛. 只是没有对手 做深入的讨论 显的肤浅了 有点象推销.

用xmldb开发的真少啊 ............    lol

个人感觉团队开发效率很低 也许是没见识过厉害的团队吧.

而且比较有趣的是 团队的骨干往往最先跳槽 做的最稳的都是团队里垫底的. 团队精神就是能者累死 闲者闲死

简单谈谈这个问题我的想法：

1、今天晚上下载了springside代码简单浏览了一下，基本上明白白衣同学为什么有这样的抱怨了。上面不理解的诸位也去看看他下载包里面的plugin子目录就会明白。

springside的plugin机制就是让你自己去写一个spring配置文件和bean类，然后他应用程序用统配符的方法加载所有classpath下面的*-context.xml文件。也就是说但凡有人的plugin里面的配置不对，整个应用就load不起来了。

这里根本问题在于plugin机制这样去设计就是错误的。plugin本身不应该直接使用一个紧密的核心机制直接拆分出来作为plugin。

2、关于单元测试和集成测试

从一般分层的角度来说，有Web Action，Service，DAO和Domain Object。

domain object我不会包含持久化逻辑，所以测试很简单很容易，往往只是一些自包含的简单逻辑。

DAO层实际上是要测试你的映射文件配置是否正确，发送HQL是否正确，关联关系维护是否正确等等。因此DAO测试我会初始化一个小一点的spring容器，包含了有关数据库，事务和DAO部分的bean，使用hsqldb的in-memory模式，Hibernate的scheme DDL是create-drop，即每个test的setUp创建数据库相关表和序列，tearDown drop所有的表和序列，以保证每个test得到的是一个干净的数据库。

目前DAO测试由于每个test都需要初始化spring容器和创建/drop 表，所以运行速度有点慢，差不多一个test需要1-2秒时间才能执行完毕(在我笔记本电脑上面)，但是我目前也找不到更快的办法了。

Service层我往往会和DAO合并，如果不合并的话，那么Service依赖的所有其他bean全部用easymock去mock，这样Service层的测试是极其简单的，mock的代价也很小。

Web Action层的测试包括Action和Interceptor，实际上是我目前感觉最头痛的部分。以前我也使用ActionProxyFactory去创建ActionProxy去测试，这样会load xwork容器，进而load整个spring容器。这就不是单元测试了，所以我现在不使用ActionProxyFactory了。

我现在直接new Action，然后调用他的execute方法，再assert。对于Action来说，准备环境还不算很麻烦，只要你不使用ActionContext，改用SesionAware接口之类的，还是很方便的。关键是不能在Action里面使用new，一旦在Action里面new了，就没有办法单元测试了，所以new真的是evil阿。我现在都是给一个set方法，然后execute方法里面写一个条件判断：
if (obj == null) obj = new ...;
这样功能代码运行的时候走new的流程，测试代码测试的时候通过set注入obj进来，绕过这个evil的new。

然后最难测试的还是Interceptor，一个是需要准备完整的ActionContext环境，另外还需要Mock request和response，用easymock Service接口和ActionInvocation接口，这些都还不算麻烦，最麻烦的是有时候需要在Interceptor里面使用valuestack，那么还要准备valuestack的环境。

最后可以写几个集成测试的例子把xwork容器和spring容器全部load起来跑跑，主要是测试集成环境是否正常。

我觉得根据上面这些办法的分拆做单元测试，还是相当不错的(除了DAO测试有点慢之外)，可以做到彻底的隔离，干净的测试单元代码。

此外值得一提的是easymock，我是因为without ejb里面Rod大力推荐而使用的，Rod说spring 60%以上的测试代码都是用easymock。我用下来easymock感觉很不错，特别是他有一个verify方法，校验expect的调用是否执行了，这样你就可以保证功能代码中的每个执行流程能够全部被测试覆盖到，相当有效的测试覆盖保证手段。

不知道大家是怎么做单元测试的，我这样做下来，效果感觉不错。但是单元测试的代码量可能会比较大一些，有些分支流程多的功能代码，其测试代码会非常庞大，因为需要测试每个流程。但是这样做下来的结果对代码信心很足，也完全不怕大规模重构。

最后做完备的单元测试我觉得还是很有必要的，它会强迫你写出来良好的功能代码(如果你代码写的不好，就没有办法单元测试)。

jmock和easymock之间，我简单看过一下jmock，如果和easymock2.1相比较，显然是easymock要胜出一大截。不过easymock需要JDK5.0(大量使用泛型来做到了非常简单的mock)。因为easymock2.1 mock出来的对象，你就好像普通对象一样去调用就可以了，而jmock则不然，还需要把method当做string的参数一样去使用，实在是太不爽了，完全不支持refactoring。

看个简单例子：


我现在只用easymock就完全够用了。其他的像request，response这类的我是自己写Mock类，spring的mock类太烦琐了，还要有学习成本，不如简单写一个就OK了。(其实request，response也可以用easymock去mock)

1 团队开发时先进行哪个层,还是平行的. 是按照模块分工呢,还是逻辑分层来分工?
2 *-context.xml 是按照模块划分,还是层划分. 这些配置是否对团队开发人员可见?
3 生产环境下与运行环境下*-context.xml是否一套?

隐隐感觉,人数越多的团队,用spring开发问题会多起来?
回到白衣问题的根上,看了半天贴,还是没得出好的办法来.