问题标签 [cdi-unit]

这是单元测试代码。当我们运行单元测试代码（SampleServiceTest2）时；AbstractDao 中注入的 EntityManager 始终为空！我们如何在单元测试期间注入 em。

*** SampleServiceTest2.java

*** SampleService.java

**** SampleLogic.java

**** SampleDataDao.java

**** AbstractDao.java

有没有人尝试过使用纯 CDI 测试 Activiti / BPMN 流程？理论上（如果我没有错过任何东西）我认为应该可以使用 f.ex。cdi-unit与 activiti-engine 和 activiti-cdi 一起用于测试进程。CDI 单元内部使用weld-se。

但我无法让它工作，我认为原因是 Activiti CDI 和 CDI 单元在不同的上下文中工作，我还没有找到如何“加入”它们（或者可能是不可能的）。

在使用 @RunWith(CdiRunner.class) 注释的测试中（如在 CDI 单元 quickstart 中）在 ProcessEngine 上使用 @Inject 并没有“触发”任何东西 - 即没有触及 Activiti 或 ProcessEngine。

假设 RequestScope 处于活动状态（使用 cdi-unit 的 @InRequestScope）

给定

• 将 Product 注入该活动请求范围

• 使用依赖生产者（带有 InjectionPoint 参数，因此必须依赖）

• 并且该生产者应该被注入一个请求范围的bean

当这失败时，请求范围 bean 的原因是

• 这是每个 CDI 的预期行为吗？
• 如果是，是因为Producer的依赖伪作用域？
• 如果 SomeCache 是应用程序范围而不是请求范围，为什么这不会失败？

SomeCache 的合理范围解决方案是什么？

范围为 SomeCache 的（不工作的）请求确实缓存了生产者生成第一个要注入的 bean 所需的一些数据。所以它可以

• 既不依赖（因为这使得缓存无用）
• 也不应该是应用程序范围或静态的（范围太广）

理想情况下，它应该自动位于注入 Product 的 bean 的同一范围内 - 在 ExpectedTest 的示例中。很可能是另一个自定义 cdi 范围，但不应依赖于定义该范围的客户端/用户开发人员。如果有任何意义，可以将其称为“传递范围依赖的 bean”。

以下代码片段足以重现我的问题：

• 要么我设置thrown属性public并得到错误org.jboss.weld.exceptions.DefinitionException: WELD-000075: Normal scoped managed bean implementation class has a public field
• 或者我删除public修饰符并得到错误org.junit.internal.runners.rules.ValidationError: The @Rule 'thrown' must be public.
• 我还尝试让public修饰符就位并@Dependent在类上添加注释范围，但出现错误org.jboss.weld.exceptions.DefinitionException: WELD-000046: At most one scope may be specified on [EnhancedAnnotatedTypeImpl] public @Dependent @ApplicationScoped @RunWith

我删除了所有不必要的代码，但这是一个相当复杂的单元测试，其中包含模拟、通过 CDI 进行的服务注入和一些测试方法，预计会引发异常。

所以我的问题是，一方面 Weld 希望所有字段都不公开，因为否则它将无法代理类，另一方面，JUnit 希望 Rule 字段公开，因为它使用反射来访问它们和setAccessible(true)由于安全管理器处于活动状态，因此不想使用该方法。如何处理这个悖论？

注意：我还发现了对此答案的提示评论，指出

你也可以用@Rule注解一个方法，这样可以避免这个问题

但是我找不到任何带有@Rule方法注释的 junit 测试示例，我打算就此提出一个单独的问题。

我有一个 CDI Web 应用程序，它有一个 ServletContextListener 在启动时初始化一些东西。

在那个 ServletContextListener 中，这（除其他外）发生了：

这工作得很好，因为这确保在其他 CDI bean 实例化之前执行 init（例如 App，它也注入 Config 本身）

但是，我无法弄清楚如何为单元测试实现这个逻辑。使用 jglue 的 CDI-Unit，我可以在我的测试类中执行此操作：

但是当我运行测试时，我不断遇到问题，因为 App 中的 @PostConstruct 需要已经启动 Config。那么，我怎么可能及时调用 Config.init() 方法呢？

我使用 cdi-unit 库测试类。测试类：

ITestCDI接口：

测试CDI类：

所以，运行这个测试我得到错误：

但是如果我直接注入TestCDI类而不是接口ITestCDI，就可以了。如何使界面正常工作？感谢帮助！

我有一个在wildfly 10 上顺利部署的JEE 项目。

我正在尝试使用 cdi-unit 库（http://bryncooke.github.io/cdi-unit/）为我的 CDI bean 编写 junit 测试

我的pom.xml样子如下：

但是我的样本测试：

由于缺少焊接类而无法初始化：

CDI-UNIT 手册在这里说它会自动使用它自己的 Weld 版本，因此无需在 pom.xml 中显式添加任何焊接库。

请问有什么帮助吗？

目前我正在尝试将 JUnit5.3.0-RC1 集成到 Weld-SE-Tes​​tframework ejb-cdi-unit 中。

在 ejb-cdi-unit:1.1.15 中可用的 JUnit5.2.0 上的第一个解决方案在某种程度上限制了 TestInstance-Classes 与 CDI 有关。我只能允许@Inject。这已经很有帮助了，但是请看

现在尝试实现 TestInstanceFactory，以避免提到的限制，我遇到了example的问题。

您可以看到在 Lifecycle PER_CLASS中工作的 Testclass ServiceTest5和两个嵌套的内部类，其中一个在 Lifecycle PER_METHOD中工作。

当前禁用内部类以避免来自 travis-ci 的邮件。

我希望，在调用方法ServiceTest5#WhenSomeEntitiesInDbExist#cantReadTestDataUsingServiceInRequiredNew之前，使用JUnit5Extension中实现的TestInstanceFactory创建 ServiceTest5的全新TestInstance，因为嵌套的内部类 WhenSomeEntitiesInDbExist具有 Lifecycle PER_METHOD。

事实并非如此。这是设计使然，还是候选版本中的错误？

将 maven-failsafe-plugin 从 2.18.1 更新到版本 2.22.2 后，cdi-unit (4.1.0) 测试开始失败并出现以下错误：

还尝试了 2.19.1 版本，结果相同。Maven 版本 3.6.1。Java 1.8.0_162-b12。适用于 Java 11。

我在项目中使用带有 java 11-openj9 的焊接和 cdi-unit，当我运行单元测试时，使用 @runWith(Cdirunner.class) 配置我收到此错误“ClassNotFoundException: org.jglue.cdiunit.CdiRunner”