使用 JUnit 测试 EJB

Question

我应该如何测试注入了 EntityManager 实例的 EJB 3.1？

一个可能的 EJB：

@Stateless
@LocalBean
public class CommentService {

    @PersistenceContext
    private EntityManager em;

    public List<Comment> findAll() {
        TypedQuery<Comment> query = em.createNamedQuery(
            Comment.FIND_ALL, Comment.class
        );
        return query.getResultList();
    }

}

一个可能的测试：

@Test
public void testFindAll() {
    List<Comment> all = service.findAll();
    Assert.assertEquals(8, all.size());
}

我只为 Java EE 开发人员使用 GlassFish 3.1 和 Eclipse Indigo。我已经尝试过这样的事情：

@Before
public void setUp() throws Exception {
    ejbContainer = EJBContainer.createEJBContainer();
    service = (CommentService) ejbContainer.getContext()
        .lookup("java:global/classes/CommentService");
}

但我得到的只是：

javax.ejb.EJBException:
No EJBContainer provider available: no provider names had been found.

Answer 1

接受的答案需要模拟大量代码，包括持久层。改为使用嵌入式容器来测试实际的 bean；否则，模拟持久层会导致代码几乎无法测试任何有用的东西。

将会话 bean 与引用持久性单元的实体管理器一起使用：

@Stateless
public class CommentService {

    @PersistenceContext(unitName = "pu")
    private EntityManager em;

    public void create(Comment t) {
        em.merge(t);
    }

    public Collection<Comment> getAll() {
        Query q = em.createNamedQuery("Comment.findAll");
        Collection<Comment> entities = q.getResultList();
        return entities;
    }
}

实体 bean：

@Entity
@NamedQueries({@NamedQuery(name = "Comment.findAll", query = "select e from Comment e")})
public class Comment implements Serializable {
    private static final long serialVersionUID = 1L;
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;

    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }
}

这个持久化单元在persistence.xml文件中定义如下：

<persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd">

  <persistence-unit name="pu" transaction-type="JTA">
    <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
    <class>org.glassfish.embedded.tempconverter.Comment</class>
    <properties>
      <property name="eclipselink.ddl-generation" value="drop-and-create-tables"/>
    </properties>
  </persistence-unit>
</persistence>

交易类型必须是JTA。

然后编写一个创建和销毁 EJB 容器（GlassFish 嵌入式容器）的测试：

public class CommentTest extends TestCase {

     private Context  ctx;
     private EJBContainer ejbContainer;

    @BeforeClass
    public  void setUp() {
        ejbContainer = EJBContainer.createEJBContainer();
        System.out.println("Opening the container" );
        ctx = ejbContainer.getContext();
    }

    @AfterClass
    public  void tearDown() {
        ejbContainer.close();
        System.out.println("Closing the container" );
    }

    public void testApp() throws NamingException {

        CommentService converter = (CommentService) ctx.lookup("java:global/classes/CommentService");
        assertNotNull(converter);

        Comment t = new Comment();
        converter.create(t);
        t = new Comment();
        converter.create(t);
        t = new Comment();
        converter.create(t);
        t = new Comment();
        converter.create(t);

        Collection<Comment> ts = converter.getAll();

        assertEquals(4, ts.size());
    }
}

接下来，添加两个依赖项（例如添加到 Maven POM）：

<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.8.2</version>
    <scope>test</scope>
    <type>jar</type>
</dependency>
<dependency>
    <groupId>org.glassfish.main.extras</groupId>
    <artifactId>glassfish-embedded-all</artifactId>
    <version>3.1.2</version>
    <scope>compile</scope>
</dependency>

拥有 dependencies、session 和 entity bean、persistence 文件、测试 文件完全按照所示实现，那么测试应该通过。 （网上的例子严重不足。）

Answer 2

可以编写针对容器运行的单元测试，但需要注意的是容器/应用服务器必须启动。由于这并不实际，因此一般方法是使用“模拟”容器来运行您的单元测试。为此，请查看 JUnitEE 或 ejb3unit：

junitee

ejb3unit

Answer 3

为什么不使用Arquillian 编写单元测试并在真实容器中运行它们！？

没有更多的嘲笑。没有更多的容器生命周期和部署麻烦。只是真正的测试！

模拟可以是战术性的，但更多时候，它们用于使代码在真实环境之外工作。 Arquillian 让您抛弃模拟并编写真正的测试。这是因为 Arquillian 将您的测试带到了运行时，让您可以访问容器资源、有意义的反馈以及对代码实际工作方式的洞察。

更多关于Arquillian features.

Answer 4

首先，确保区分单元测试和集成测试。 JUnit 只是一个帮助您组织和运行测试的框架，但您必须确定测试的范围。

我假设您有兴趣定义CommentService.findAll() 的单元 测试。那是什么意思？这意味着我将验证调用 findAll() 方法会导致 CommentService 调用由 FIND_ALL 字符串常量命名的命名查询。

由于依赖注入和存根，您可以使用例如Mockito 存根 EntityManager。对于单元测试，我们只关注findAll() 中的业务逻辑，所以我也不会测试评论服务的查找——测试评论服务是否可以被查找并连接到适当的实体manager 实例在集成测试的范围内，而不是单元测试的范围内。

public class MyCommentServiceUnitTest {
    CommentService commentService;
    EntityManager entityManager;

    @Before
    public void setUp() {
        commentService = new CommentService();

        entityManager = mock(EntityManager.class);
        commentService.setEm(entityManager); // inject our stubbed entity manager
    }

    @Test
    public void testFindAll() {
        // stub the entity manager to return a meaningful result when somebody asks
        // for the FIND_ALL named query
        Query query = mock(Query.class);
        when(entityManager.createNamedQuery(Comment.FIND_ALL, Comment.class)).thenReturn(query);
        // stub the query returned above to return a meaningful result when somebody
        // asks for the result list
        List<Comment> dummyResult = new LinkedList<Comment>();
        when(query.getResultList()).thenReturn(dummyResult);

        // let's call findAll() and see what it does
        List<Comment> result = commentService.findAll();

        // did it request the named query?
        verify(entityManager).createNamedQuery(Comment.FIND_ALL, Comment.class);
        // did it ask for the result list of the named query?
        verify(query).getResultList();
        // did it return the result list of the named query?
        assertSame(dummyResult, result);

        // success, it did all of the above!
    }
}

通过上面的单元测试，我测试了findAll() 实现的行为。单元测试验证获得了正确的命名查询，并且命名查询返回的结果返回给被调用者。

更重要的是，上面的单元测试验证了findAll() 的实现是正确的，独立于底层JPA 提供者和底层数据。我不想测试 JPA 和 JPA 提供程序，除非我怀疑第 3 方代码中存在错误，因此删除这些依赖项可以让我将测试完全集中在 Comment 服务的业务逻辑上。

可能需要一些时间来适应使用存根测试行为的心态，但它是测试 EJB 3.1 bean 的业务逻辑的一种非常强大的技术，因为它允许您隔离每个测试的范围并将其缩小到排除外部依赖。