在TDD中,为什么OpenEJB和为什么选择Arquillian? [英] In TDD, why OpenEJB and why Arquillian?

查看:144
本文介绍了在TDD中,为什么OpenEJB和为什么选择Arquillian?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我是一个Web开发人员,在一些Java EE开发中(Richfaces,Seam 2,EJB 3.1,JPA)。为了测试JPA,我使用超音速和Mockito。但是我缺乏更深入的EJB知识。



有些人可能认为我们应该使用OpenEJB和Arquillian,但是为什么?
什么时候需要做容器依赖测试?有什么可能的测试场景,我需要OpenEJB和Arquillian?



请启发我:)

解决方案

在这种情况下有两个方面。


  1. 单元测试。这些旨在非常快(在几秒钟内执行整个测试套件)。他们测试了很小的代码块,即一种方法。要实现这种粒度,您需要使用Mockito来模拟整个环境。您不感兴趣:

    • 调用EntityManager并将实体放入数据库,

    • 测试交易,

    • 进行异步调用,

    • 点击JMS终端等。


您可以模拟整个环境,并分别测试每种方法。 单元测试是细粒度,并且速度快。这是因为您可以在每次在代码中进行重要更改时执行它们。如果他们更复杂和耗时,开发人员就不会像他应该那样频繁地按下测试按钮。


  1. 集成测试。这些速度较慢,因为您想要测试模块之间的集成。你想要测试他们是否相互对话,即:

    • 是按照你期望的方式传播的交易,

    • 如果您调用您的业务方法没有任何事务,那么会发生什么,

    • 从WebServices客户端发送的更改真的会触发您的端点方法,并将数据添加到数据库?

    • 如果我的JMS端点抛出一个ApplicationException - 它会正确地回滚所有的更改吗?




    1. 如您所见,集成测试是粗粒度,因为它们在容器中执行(或者基本上是在类似生产的环境中) 慢得多这些测试通常在每个代码更改后都不被开发人员执行。



      当然,您可以在嵌入式模式下运行EJB容器,就像您可以执行JPA Java SE。关键是人造环境给你提供基本的服务,但是你会结束调整,而不是真正的容器中的灵活性。



      Arquillian使您能够在您选择的容器上创建生产环境,并在此环境中执行测试(使用数据源,JMS目标以及您期望在生产环境中看到的许多其他配置。)



      希望有帮助。


      I'm a web developer ended up in some Java EE development (Richfaces, Seam 2, EJB 3.1, JPA). To test JPA I use hypersonic and Mockito. But I lack deeper EJB knowledge.

      Some may argue that we should use OpenEJB and Arquillian, but for what? When do I need to do container dependent tests? What are the possible test scenarios where I need OpenEJB and Arquillian?

      Please enlighten me :)

      解决方案

      There are two aspects in this case.

      1. Unit tests. These are intended to be very fast (execute the whole test suite in seconds). They test very small chunks of your code - i.e. one method. To achieve this kind of granularity, you need to mock the whole environment using i.e. Mockito. You're not interested in:
        • invoking EntityManager and putting entities into the database,
        • testing transactions,
        • making asynchronous invocations,
        • hitting the JMS Endpoint, etc.

      You mock this whole environment and just test each method separately. Unit tests are fine-grained and blazingly fast. It's because you can execute them each time you make some important changes in code. If they were more complex and time-consuming, the developer wouldn't hit the 'test' button so often as he should.

      1. Integration tests. These are slower, as you want to test the integration between your modules. You want to test if they 'talk' to each other appropriately, i.e.:
        • are the transactions propagated in the way you expect it,
        • what happens if you invoke your business method with no transaction at all,
        • does the changes sent from your WebServices client, really hits your endpoint method and it adds the data to the database?
        • what if my JMS endpoint throw an ApplicationException - will it properly rollback all the changes?

      As you see, integration tests are coarse-grained and as they're executed in the container (or basically: in production-like environment) they're much slower. These tests are normally not executed by the developer after each code change.

      Of course, you can run the EJB Container in embedded mode, just as you can execute the JPA in Java SE. The point is that the artificial environment is giving you the basic services, but you'll end with tweaking it and still end with less flexibility than in the real container.

      Arquillian gives you the ability to create the production environment on the container of your choice and just execute tests in this environment (using the datasources, JMS destinations, and a whole lot of other configurations you expect to see in production environment.)

      Hope it helps.

      这篇关于在TDD中,为什么OpenEJB和为什么选择Arquillian?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆