对于我正在处理的（学校）项目，我们必须开发一个中型 Java 应用程序，在我们的案例中使用 javaFX 和 java CDI 依赖注入，我们有一个基于 groovy 文件的脚本化 jenkins 管道，该文件检查每个拉取请求以便分支不符合质量要求或失败的建筑不能合并。
现在我们遇到的问题是，目前只有 25% 的开发人员实际运行应用程序来测试他们的添加是否有效，因为该项目还处于早期阶段，我们目前正在开发的许多功能还没有被 GUI 使用. 其他 75% 的开发人员使用 JUnit 单元测试和集成测试来检查他们的代码是否有效。虽然我们可以尝试说每个人都需要在发出拉取请求之前运行实际的应用程序，以检查 java CDI 依赖注入是否没有运行时错误。人就是人，并不总是倾听，所以我们经常将代码进行开发，这些代码在 maven 上成功，但由于依赖注入问题而无法运行。
在 jenkins 构建中检查是否存在将弹出运行时的 java CDI 依赖项注入问题的最简单方法是什么？
我们已经使用 JUnit，但目前并非所有测试都使用焊接注入进行测试，如果有可能进行单个测试来检查所有依赖注入问题，这些问题也可以代替基于 jenkins 的解决方案。
您的 CI（持续集成）方法很好。测试所有 PR 是一种方法，你只需要决定应该执行什么样的测试。JUnit 风格，还是集成测试？也许两者都有？
CDI 本身有一个部署验证阶段，在该阶段它会在引导时检查一切是否正常——bean 是否具有钝化能力（那些应该），是否可以满足所有声明的注入点等等。这可以在运行时捕获许多用户错误，因此只需部署应用程序即可显示它。您可以并且应该使用 Arquillian 来设置一个与实际运行时环境非常相似的测试环境。请注意，此验证（实际上没有验证）无法检查动态解析错误。例如，当您使用Instance<Object>然后尝试解析不存在的 bean 时不进行检查。
如果这不是您想要的，那么您可以考虑weld-junit extension。这利用了 junit（4 或 5）来引导 Weld SE 容器，您可以在其中玩弄您的 bean 并测试它们。查看项目中的自述文件和测试以获取示例。这并不反映纯粹的 EE 环境，而是更像是一种带有 CDI 的 junit 风格测试，并且易于上手。
请注意，使用 Jenkins，您可以为每个 PR 设置多个任务。例如，您可以让它运行所有 JUnit 测试以及所有集成 (Arquillian) 测试。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句