Maven下多个Spring启动应用程序的端到端集成测试

Question

Spring在Maven构建的验证阶段,为多个引导应用程序运行端到端集成测试的推荐方法是什么？

基本上,我有一个多模块Maven项目,其中几个模块是独立的弹簧启动应用程序.这些单独的应用程序有自己的数据源配置,带JMS队列的集成流等.例如,应用程序A将轮询数据库中的事件,当发生这种情况时,它会生成JSON数据文件并将消息放入JMS队列.应用程序B正在轮询JMS队列,因此选择消息,读取文件,使用另一个数据库执行某些处理,并将消息放在不同的队列中.然后,应用程序C将接收该消息等.

我已经为各个应用程序设置了集成测试; 这些在Maven故障安全插件下运行.但是,我想整合测试整个系统,端到端,在Maven下.我在专用于此任务的项目中设置了一个单独的模块,因此希望此模块的验证构建阶段使用其他相关模块进行端到端测试.

这样做有最佳实践方法吗？我看到3种可能的方式:

1. 将每个应用程序的配置加载到同一应用程序上下文中.但是,由于存在多个数据源等,这会产生冲突,因此这些数据源都必须手动配置才能实现端到端集成测试 - 所以这对我来说似乎不对.
2. 将每个应用程序作为一个单独的进程启动 - 然后如何正确地跟踪它们并确保它们在测试模块构建停止/崩溃/等时关闭？
3. 有没有办法在同一个进程中轻松加载单独的Spring引导应用程序,每个应用程序都有自己的配置上下文？这似乎是最明智的选择.有关Mavenbuild/failsafe插件的任何注意事项吗？

Answer 1

只是为了跟进并说出我最终做的事情(继续运作良好):

• 我在我的测试模块中创建了以下Maven配置文件:默认情况下"默认"跳过测试(我们使用jgitflow插件,因此只需要在明确请求时运行端到端测试),"standalone-e2e"用于端到端测试不需要外部资源,如数据库(针对希望进行完整端到端测试的开发人员),以及"集成-e2e",用于使用真实数据库等进行端到端测试(可以作为CI).弹簧配置文件(由相应的Maven配置文件激活)控制各个组件的配置.
• 对于standalone-e2e,相关的插件,如activemq-maven-plugin,hsqldb-maven-plugin等,作为端到端测试的一部分启动(以后关闭)资源,在使用build-helper保留的端口上运行maven-plugin.该过程的exec-Maven的插件,用来启动所有在预集成测试阶段要测试的组件(如标准春季启动的应用程序),并且它会自动关闭它们在后集成测试的护理相.Spring配置和特定的Maven测试依赖关系会处理其他资源,例如虚假的FTP服务器.在所有资源和组件运行之后,测试代码本身然后根据需要填充数据库和文件系统,并使用JMS触发流(并等待相应的回复等).
• 集成的e2e配置文件几乎完全相同,但使用在关联的Spring属性中配置的"真实"外部资源(在我们的示例中,Amazon SQS队列,MySQL数据库等).
• 测试所需的所有文件(例如数据文件,HSQLDB文件,日志文件等)都是在"目标"构建目录下创建的,因此可以轻松检查此区域以查看测试期间发生的情况,并允许"mvn clean"清除一切.

我希望这很有用 - 我发现无论我需要做什么,都可以使用Maven插件来处理它!

Answer 2

非常好的问题!我自己会对其他人的回答感兴趣.我会分享我的意见.

首先,在我的理解中你应该知道你想要测试什么.集成测试应该至少与其中的一部分应用程序一起使用,并确保您开发的组件在半真实环境中正常工作.好像你已经做到了.

现在,关于系统测试(我有意区分集成和系统测试).这些应该"模仿"QA人:)所以,他们将系统视为黑盒子.他们无法调用任何内部API并运行实际流程.端到端测试IMO属于这一类.

在这种情况下,您希望针对像生产中那样部署的系统检查它们,并使用类似生产的类路径.

所以我真的不相信选项1就像你一样.

关于选项3,我不确定它是否也是一个好的解决方案.即使你用不同的应用程序上下文运行你的东西(我不太了解Spring引导,所以我不能在技术上对它进行评论),在我的理解中它们将在运行时共享相同的类路径,所以可能你有风险在你的第三方之间发生冲突(虽然我知道spring boot本身定义了很多版本的jar,你知道我的意思),特别是当你只升级一个模块并且可能改变了依赖关系时.所以当你运行这个方法时,你真的不知道内存中究竟运行了什么.

因此,对于端到端测试,我会选择选项2.关于同步,可能选项是在应用程序级别结合操作系统级别的进程状态跟踪实现某些逻辑.我想评论的另一点是,端到端测试通常仍然是功能测试(它们检查系统的功能行为),因此通常不应检查每次测试中的系统崩溃.如果检查每个流的系统崩溃,这些测试将太慢.当然,您可以维护一个相对较小的测试套件来检查角落情况.

希望这可以帮助