用Cactus来测试EJB,Servlet

这是个好东东，不错

好像你投到IBM去了，今天才发现。恭喜
http://www-900.ibm.com/developerWorks/cn/java/l-Cactus/index.shtml

:)
呵呵。。是啊。多提意见

我在实践中发现，最困难的测试和调试在于流程中，就是说，前台Jsp的几个页面组成一个流程，就象你的工作流，后台在每个流程要做很多事情，而且后面一个流程的数据是依赖前面一个流程的数据，这样，就很难象你在文中一样自己制造插入用户名的数据，这些数据是前面流程动态产生的。

不知道cactus对于这样的测试是如何处理的。

测试是面向接口的，而不是流程。我们要测试的是我们的公开接口的准确性，如果你的流程控制有专门的类来做，那么当然也可以测试这个控制类，只要针对它的public interface

问题是这个控制类是由用户来控制的。这种情况在复杂系统里很多，特别是一些创建过程，一个用户在创建过程中，会根据自己的需要选择不同的参数，导致到下一步的结果都不一样。

Junit,cactus都是单元测试工具，针对的测试对象是public interface，保证单元功能的健壮性。如果你的类这些public interface都测试通过的话，当然数据是需要创建的，那么他们之间的协作只是参数是否正确的问题了。

每个单元正确了，但是当这些单元协同工作了，还会不正确，有这样的情况，这是因为你在单元测试不可能穷举所有的数据去测试单元，而一个单元的输出的结果可能是随机的，这些结果一旦作为下个单元的输入参数，就可能导致下个单元运行出错。

这种情况一旦发生，我们会很郁闷，看来cactus是帮不了忙，还得我在现场运行时加入system.out一个个数据跟踪。

为什么结果是随机的？

比如
某个单元输入参数有a和b，它的输出结果就很多，几乎是随机的。

if a==1 && b==1
   这是一个结果
if a==2 && b==1
   这是一个结果
.....

a和b是上一个单元的结果，我如果能预测的话将是很累的一件事情，但是如果使用cactus，它就逼迫我去预测出来a和b的可能组合，累不累？呵呵

还不如，架上现场，跟踪system.out.println(a+b);

这只是一个例子，a和b可能还是逻辑判断。

呵呵。。这个倒是个问题。不过你用system.out也一样不能全部都测试，如果能，为什么用cactus不行。如果用cactus,那么测试将是自动的，在重构的时候可以很好的保障代码地准确性。

用system.out可以追踪数据，这个功能对于测试非常重要。
就是设置断点。