struts和webwork双体验

gigix说这些话有个潜在前提：他提倡的是敏捷开发那一套过程。
如果你没有采用相关的一些原则，他的话对你是无用的。
至于是否需要测试先行，快速构建是另外一个话题。

没关系，你说说看你怎么测Struts action吧。

对于需求的变更，要看什么样子的需求变更，不同的变更对于系统的影响是不一样的。
现在流行的一些web框架，就代码角度未必会少很多代码。但它的好处就体现在维护上，1，首先，这类技术现在很普及了，找个替代的人相对容易了，
2，一定的层次结构，更容易进行代码分工和代码隔离，也就方便了维护。
另：我很敬畏有1k个servlet的系统。还是不要让我碰上这类系统。

俺现在做的一是监督：就目前来看，大多数数据库应用主要是业务驱动的，涉及的技术方面比较窄，所以所犯错误的类型就相应的少。程序员代码提交后，找人抽查代码，能发现某个人概念不清楚或者用法不正确的地方。
事后的验证：根据需求，验证其正确性（经常性工作）。
虽然测试不是为了验证正确性的，但是除了有些明白软件的变态客户之外，程序员还是pm，经常会不自觉地有这样的做法，实际上也很有效。

说的完全不是一回事……
这种测试又不能自动运行。

我只是在发现自动测试目前对我除了增加工作量之外，起不到实质性的帮助之后采取的措施，not elegant，but works
对于大多数web应用，自动测试不能解决问题，我只是觉得如果经常把测试作为抨击struts的理由，不是很有说服力。

前面有哥们说过了，如果你还没有采用TDD，关于测试的话题就可以打住。至于TDD有什么好处，说过太多遍了，不想重复。

我插一句嘴，如果能用cactus和httpunit对struts做容器内测试呢,那个能减小不能测试的缺点吗？

可以减小，但问题仍然严重。你要mock一大堆东西，比起直接new出一个action然后execute，复杂度差太远了。

使用StrutsTestCase进行Struts的Action测试非常简单，当然也是支持自动测试的，我现在就使用这个做测试，修改一下可以整合Spring。
非常赞同设计也必须考虑测试的问题。