我最近开始使用大型的遗留企业Java应用程序。它主要基于Websphere Commerce 6.它包含EJB 1.x和2.x的混合以及可以直接挂钩到Commerce API的相当多的代码。
我在尝试破坏依赖性并仔细重构代码的一小部分时引入了第一个单元测试。我们一直在探索使用集成测试框架的想法,使创建测试的过程不那么脆弱和耗时。
Arquillian被认为是集成测试的一个很好的选择。然而,它看起来面向更“现代”的应用;大多数示例都使用Java EE 5+和Maven。我们正在使用J2EE和Ant。我们目前也与Java 1.4绑定,尽管我们可能会迁移到Java 5,但我们不会很快升级到EJB 3.x.我们也很可能坚持使用Ant。
考虑到这些限制因素,是否可以使用Arquillian?或者,对于遗留企业Java应用程序的集成测试是否存在更好的替代方案?
答案 0 :(得分:4)
Arquillian被认为是集成测试的一个很好的选择。然而,它看起来面向更“现代”的应用;大多数示例都使用Java EE 5+和Maven。我们正在使用J2EE和Ant。我们目前也与Java 1.4绑定,尽管我们可能会迁移到Java 5,但我们不会很快升级到EJB 3.x.我们也很可能坚持使用Ant。
考虑到这些限制因素,是否可以使用Arquillian?
注意:我是Arquillian的贡献者。在我的回答中,我试图不偏不倚。
这实际上取决于测试的执行方式。如果您尝试使用Arquillian对容器内测试的支持,那么您不太可能找到解决方案。 WebSphere Commerce 6使用WebSphere 6.0作为底层容器,目前Arquillian不支持。如果您可以假设使用以WAS 7.0或8.0为基础的WebSphere Commerce版本,那么我的大多数答案都可以忽略,因为这些容器都受支持。
您可以尝试使用@RunAsClient
注释而不是容器从客户端运行测试,这更有可能成功。请注意,您需要在没有@Deployment
注释方法的情况下以某种方式执行部署,因为前面提到的Arquillian中没有对WAS 6的支持。
如果您打算使用Ant而不是Maven,那么唯一的要求是所有依赖项都存在于类路径中。不幸的是,Arquillian没有uber JAR或发行版,所以现在你需要事先知道所有依赖项。
注 - 与其他更新的容器相比,在WebSphere 6.0中支持Arquillian可能不是一项简单的活动:
或者,对于遗留企业Java应用程序的集成测试是否存在更好的替代方案?
我通常建议人们为Cargo遗留应用程序使用functional testing和JUnit混合,但即使是Cargo似乎也不支持WebSphere 6.0。
如果您愿意将JUnitEE TestRunner打包到存档中,您可能会发现JUnitEE更适合您的需求;请注意,JUnitEE的最后一个版本是在2004年,而mailing list有点不活跃,所以YMMV。