基于 Java™ 的 Web 开发领域近出现了丰富的竞争性技术。启动新项目的开发人员可以在许多不同的框架之间进行选择，包括 JavaServer Faces、Tapestry、Shale、Grails 和 Seam （只列举众多机灵的名称中的几个）。很快，我们可以通过 JRuby 框架在 Java 编程中使用 Ruby on Rails 了！

但在不远的过去，只有一个 Java Web 开发框架卓然而立。Struts 是第一个在 Java 世界掀起风暴的框架，而且多年以来，好像是如果一个项目不用 Struts 构建没有前途一样。没有 Struts 经验的 Java 开发人员很稀少，也很不幸，像的开发人员没有听说过 Ruby on Rails 一样。
 
提高代码质量
不要错过 Andrew 的附带 讨论组 ，可以得到迫切问题的答案。

即使 Struts 正慢慢地从舞台中央退去（原来的基本框架，现在叫做 Struts 1，似乎正在退出 Web 框架的历史舞台），但它的遗产仍然存在，既以 Shale （请参阅 参考资料）的形式存在，又以运行在世界各地的成千上万的遗留应用程序的形式存在。因为许多企业宁愿测试和维护这些应用程序而不愿意花钱重新编写它们，所以理解 Struts 应用程序的一些缺陷，以及如何围绕它们进行重构，是个好主意。

这个月，我要把以质量为核心的方法用于 Struts 应用程序的测试场景。结合现实，这个场景围绕着普遍的 Struts 构造：深受喜爱的 Action 类。

1、2、3，行动！

Struts 的革新之一是把 Web 开发从 Servlet 移进了 Action 类。这些类包含业务逻辑，以 JavaBean 的形式（通常叫做 ActionForm）把数据传送到 JSP。然后 JSP 处理应用程序视图。Struts 到 MVC 的方法非常容易掌握，以至于许多开发团队冒失地闯进去，而很少考虑与 Action 相关的长期设计和维护问题。

 
测试和复杂性

我已经发现，在开发人员的测试和代码的复杂性之间存在强烈的相关性：没有其中一个的地方，通常也没有另一个。高度复杂的编码难于测试，结果是很少有人会真正为它编写测试。反过来，编写测试可以降低代码的复杂性。因为给复杂代码编写测试更困难，而且因为会边走边测试，所以会发现自己朝着更简单的代码构造前进。如果代码太复杂，而且知道不得不测试它，您可能会在测试之前对复杂性进行重构。不论如何看待，为不那么简单的代码编写测试是消灭代码复杂性的好实践。

虽然在那个时候（过去的自由时光啊）可能没人想过，但 Struts Action 类通常成为复杂性的保护所。像在老的 EJB 架构中声名狼籍的会话 Facade 一样，Action 类会成为特定业务过程的严格伪装，或者通过直接调用 EJB，通过打开数据库连接，或者通过调用其他高度依赖的对象。Action 类还有输出耦合（通过 java.servlet API 包中的对象，例如 HttpServletRequest 和 HttpServletResponse），从而极难把它们隔离出来测试。

隔离出来测试 Action 类的困难意味着它们可以很容易变得相当复杂 —— 特别是当它们变成越来越深入地与遗留框架耦合的时候。现在我们来看这个困难在真实的遗留应用程序场景中作用的情况。

测试挑战

即使简单的 Struts Action 类也会是个测试挑战。例如，以清单 1 中的 execute() 方法为例；它看起来足够简单，可以测试，但是真的么？