0

Is there a good way to unit test BMT in EJB 3.x, outside the container. I believe that it would make sense to test transactions right when we are coding it. IMHO it is important to test what we code right from the first possible stage. So, if there is a nice way which is simple and does not take too much time to execute, to test BMT, then it would be really welcome.

At present, I am using an in-memory DB to test my JPAQL in EJB outside the container. I use unitils-DBUnit to inject test data in my DB. So, as the test bed is set, in special scenarios where I need to test the BMT, what should I do?

P.S : I have taken a look into tools like Bitronix, but I am really not sure if it would help my case. I need some tool that is really performance intensive and light so that it does not frustrate the developers - this is unit testing. Kindly give me your inputs on this too. According to you, would such a tool be good for my purpose. If yes, do you also have any examples that I can refer to?

Thanks a lot

Bala
  • 1,193
  • 2
  • 12
  • 34
  • Are you insisting on using outside of the container tests? Are there any particular reasons why you don't want to use in-container tests? – Piotr Nowicki Nov 17 '11 at 16:53

2 Answers2

0

Do you really need to test "outside the container", or is "outside the server" sufficient? If the former, have you looked at the embeddable EJB container support in EJB 3.1? The embeddable EJB container runs in a standalone Java process (ideal for unit tests), and BMT is required for the embeddable EJB container per table 27 (section 21.1) of the EJB 3.1 spec.

Brett Kail
  • 33,593
  • 2
  • 85
  • 90
  • Thanks for the reply. I actually do not want to use embeddable containers for unit testing (while still in the process of development). May be I can use it later for integration testing. This is because, my bean still needs to be deployed every time in the embeddable container and this still costs a few more seconds. Ofcourse this small time should be fine, but I am trying to explore if there are other better methods before I resort to this :-) – Bala Nov 18 '11 at 09:04
  • Also in this case, will it not become possibly an integration test? Because, when I deploy my bean in the container which I instantiate, it will start looking for its dependencies. In this case, I may not be able to use mocks anymore... Am I right. Please correct me if I am wrong, as I am new to this. Thanks. – Bala Nov 21 '11 at 15:49
  • You're correct, but that's also true for supplying a UserTransaction. Should you be mocking that and the DataSource as well? – Brett Kail Nov 21 '11 at 18:50
  • No. I will not be mocking the datasource. For testing dao like beans which may have a lot of handwritten queries, I directly test it using JPA-Hibernate in JavaSE. When it comes to transactions, I was looking for something like this which can run on my JavaSE and which does not require deployment everytime and also allows scope for mock injections... :-) – Bala Nov 22 '11 at 08:48
  • Actually, I checked Bitronix during the weekend and it is serving my purpose to an extent. But, I would like to know more (because there is always a better solution :-)) from all, before I could post my findings in this forum. – Bala Nov 22 '11 at 08:52
0

For unit testing transactions, there should be a complete transaction manager which is standalone and takes very less time to execute. It should not force deployment of any beans or jars.

Bitronix is working fine and satisfies my purpose. It takes less than a second to execute the tests. So, I do not have to mock my transactions anymore and I can be sure that the transactions work as I expect them to work before my code moves to the Integration testing phase. I have also seen positive responses about Atomikos, but I never tried it. May be I can update this thread when I evaluate Atomikos too.

Bala
  • 1,193
  • 2
  • 12
  • 34