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

核心提示： 清单 2. ChangePasswordForm 的验证逻辑if((newPassword1==null)||(newPassword1.length()<1)){errors.add("newPassword1",newActionError("error.

清单 2. ChangePasswordForm 的验证逻辑

if((newPassword1　==　null)　||　(newPassword1.length()　<　1))　{　
　errors.add("newPassword1",　
　　new　ActionError("error.changePassword.newPassword1Required"));　
}　
　
if((newPassword2　==　null)　||　(newPassword2.length()　<　1))　{　
　errors.add("newPassword2",　
　　new　ActionError("error.changePassword.newPassword2Required"));　
}　
　
if((newPassword1　!=　null)　&&　(newPassword2　!=　null))　{　
　if(!newPassword1.equals(newPassword2))　{　
　　errors.add(ActionErrors.GLOBAL_ERROR,　
　new　ActionError("error.changePassword.passwordsDontMatch"));　
　}　
}　

清单 1 和 清单 2 的代码不特殊也不特定于某个领域。它是无数应用程序中都包含的简单口令修改逻辑。如果正在测试 Struts 遗留应用程序，将不得不花些时间处理口令逻辑，但是如何用可重复的方式测试它呢？

两个测试用例

在企图为 清单 1（间接的是 清单 2）的代码编写测试之前，可能想确定实际需要测试什么。在这个具体示例中，逻辑清楚地是为了方便用户口令的修改；所以，应当编写至少两个层次的测试用例：

口令修改在数据正确时是否工作？

如果数据不正确，口令是不是不 修改？

这些测试不会太容易只是个假设。不仅需要对付 Struts，还必须处理数据层以及数据层与数据库暗含的耦合！在面对复杂性时，我的第一本能是寻求帮助，在这个示例中，是以 JUnit 的 StrutsTestCase 的形式。