在 TDD 中，为什么选择 OpenEJB 以及为什么选择 Arquillian？答案

【问题标题】：In TDD, why OpenEJB and why Arquillian?在 TDD 中，为什么选择 OpenEJB 以及为什么选择 Arquillian？
【发布时间】：2011-10-09 07:01:11
【问题描述】：

我是一名 Web 开发人员，最终从事了一些 Java EE 开发（Richfaces、Seam 2、EJB 3.1、JPA）。为了测试 JPA，我使用了 hypersonic 和 Mockito。但我缺乏更深入的 EJB 知识。

有些人可能会争辩说我们应该使用 OpenEJB 和 Arquillian，但是为了什么？我什么时候需要进行容器相关测试？我需要 OpenEJB 和 Arquillian 的可能测试场景有哪些？

请赐教:)

【问题讨论】：

【解决方案1】：

这个案例有两个方面。

单元测试。这些旨在非常快（在几秒钟内执行整个测试套件）。他们测试非常小的代码块 - 即一种方法。要实现这种粒度，您需要使用 Mockito 来模拟整个环境。您对以下内容不感兴趣：
- 调用EntityManager并将实体放入数据库，
- 测试交易，
- 进行异步调用，
- 点击 JMS 端点等。

您模拟整个环境并单独测试每个方法。 单元测试是细粒度的，而且速度极快。这是因为您可以在每次对代码进行一些重要更改时执行它们。如果它们更复杂、更耗时，开发人员就不会像他应该的那样频繁地点击“测试”按钮。

集成测试。这些速度较慢，因为您想测试模块之间的集成。您想测试他们是否适当地相互“交谈”，即：
- 交易是否以您期望的方式传播，
- 如果调用业务方法时根本没有事务会发生什么，
- 从您的 WebServices 客户端发送的更改是否真的会影响您的端点方法并将数据添加到数据库中？
- 如果我的 JMS 端点抛出 ApplicationException - 它会正确回滚所有更改吗？

如您所见，集成测试是粗粒度的，并且当它们在容器中执行时（或者基本上：在类似生产的环境中），它们的速度要慢得多。每次代码更改后，开发人员通常不会执行这些测试。

当然，您可以在嵌入式模式下运行 EJB 容器，就像在 Java SE 中执行 JPA 一样。关键是人工环境为您提供了基本服务，但您最终会对其进行调整，但最终的灵活性仍然低于真实容器。

Arquillian 让您能够在您选择的容器上创建生产环境并在此环境中执行测试（使用数据源、JMS 目标以及您希望在生产环境中看到的大量其他配置。）

希望对你有帮助。

【讨论】：

谢谢你，完美的答案。就我而言，JMS 部分特别有趣。
很高兴我能帮上忙 :-)
好文章。我很好奇“关键是人工环境正在为您提供基本服务，但您最终会对其进行调整，但最终的灵活性仍然低于真实容器中的灵活性”是什么意思。 EJBContainer API 背后的理念是您使用的是真正的 EJB 容器。合规性或行为不应有任何差异。
@DavidBlevins 感谢您指出这一点。是的，你是对的——服务是一样的。我更多地指的是类似仪器的服务，例如控制 EJB 的池或特定于将在生产环境中设置的具体应用程序服务器的设置。我想我只是没有正确地用文字表达。作为旁注，我认为最好将容器的配置与测试代码松散耦合。它使代码更清晰、更简洁（当然在我看来）。
@PedroKowalski 是的。使用旧的 InitialContext 方法，您可以使用 jndi.properties 文件。在规范关闭后，我突然想到我们忘记为 EJBContainer API 添加类似的东西，比如 embeddable.properties 文件或类似的东西。当然，对于 OpenEJB，您可以使用普通的系统属性或 openejb.xml 文件。

【解决方案2】：

我今年参加了 Devoxx，并有机会回答 JBOSS 伙计们这个问题。一些测试场景（我设法写下来的东西）：

【讨论】：