追求代码质量 - 测试Struts遗留的应用程序 - 编程入门网
追求代码质量 - 测试Struts遗留的应用程序时间:2010-12-12 IBM Andrew Glover基于 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 相关的 长期设计和维护问题。 测试和复杂性 我已经发现,在开发人员的测试和代码的复杂性之间存在强烈的相关性:没 有其中一个的地方,通常也没有另一个。高度复杂的编码难于测试,结果是很少 有人会真正为它编写测试。反过来,编写测试可以降低代码的复杂性。因为给复 杂代码编写测试更困难,而且因为会边走边测试,所以会发现自己朝着更简单的 代码构造前进。如果代码太复杂,而且知道不得不测试它,您可能就会在测试之 前对复杂性进行重构。不论如何看待,为不那么简单的代码编写测试是消灭代码 复杂性的好实践。 虽然在那个时候(过去的自由时光啊)可能没人想过,但 Struts Action 类 通常成为复杂性的保护所。像在老的 EJB 架构中声名狼籍的会话 Facade 一样 ,Action 类会成为特定业务过程的严格伪装,或者通过直接调用 EJB,通过打 开数据库连接,或者通过调用其他高度依赖的对象。Action 类还有输出耦合( 通过 java.servlet API 包中的对象,例如 HttpServletRequest 和 HttpServletResponse),从而极难把它们隔离出来测试。 隔离出来测试 Action 类的困难意味着它们可以很容易变得相当复杂 —— 特别是当它们变成越来越深入地与遗留框架耦合的时候。现在我们来看这个困难 在真实的遗留应用程序场景中作用的情况。 测试挑战 即使最简单的 Struts Action 类也会是个测试挑战。例如,以清单 1 中的 execute() 方法为例;它看起来足够简单,可以测试,但是真的么? 清单 1. 这个方法看起来容易测试……
|
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务,公司网站:http://www.lingzhong.cn 为了给广大客户了解更多的技术信息,本技术文章收集来源于网络,凌众科技尊重文章作者的版权,如果有涉及你的版权有必要删除你的文章,请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息,谢谢! |