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

核心提示： 测试和复杂性我已经发现，在开发人员的测试和代码的复杂性之间存在强烈的相关性：没有其中一个的地方，追求代码质量: 测试 Struts 遗留的应用程序(2)，通常也没有另一个，高度复杂的编码难于测试，例如，以清单 1 中的 execute() 方法为例；它看起来足够简单，结果是很少有人会真正为它编写

测试和复杂性

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

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

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

测试挑战

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

清单 1. 这个方法看起来容易测试……

public　ActionForward　execute(ActionMapping　mapping,　ActionForm　aForm,　
　HttpServletRequest　req,　HttpServletResponse　res)　throws　Exception　{　
　try{　
　　
　　String　newPassword　=　((ChangePasswordForm)aForm).getNewPassword1();　
　　String　username　=　((ChangePasswordForm)aForm).getUsername();　
　
　　IUser　user　=　DataAccessUtils.getDaos().getUserDao().findUserByUsername(username);　
　
　　user.digestAndSetPassword(newPassword);　
　　DataAccessUtils.getDaos().getUserDao().saveUser(user);　
　
　}catch(Throwable　thr){　　　
　　　return　findFailure(mapping,　aForm,　req,　res);　
　}　
　return　findSuccess(mapping,　aForm,　req,　res);　
}