追求代码质量: 测试 Struts 遗留的应用程序

核心提示：基于 Java™ 的 Web 开发领域最近出现了丰富的竞争性技术，启动新项目的开发人员可以在许多不同的框架之间进行选择，追求代码质量: 测试 Struts 遗留的应用程序，包括 JavaServer Faces、Tapestry、Shale、Grails 和 Seam （只列举众多机灵的名称中的几个），很快

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

但就在不远的过去，只有一个 Java Web 开发框架卓然而立。Struts 是第一个在 Java 世界掀起风暴的框架，而且多年以来，好像是如果一个项目不用 Struts 构建就没有前途一样。没有 Struts 经验的 Java 开发人员很稀少，也很不幸，就像今天的开发人员没有听说过 Ruby on Rails 一样。

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

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

1、2、3，行动！

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