Category Archives: Testing

Arquillian and TomEE embedded: multiple webapps, different CDI extensions


TomEE embedded made several progresses recently and it is nice to use with Arquillian. Since it is fully integrated with Arquillian you can deploy 2, 3 or much more webapps in the TomEE embedded instance…but then you have an issue: CDI. CDI extension mecanism is based on Java ServiceLoader mecanism. It means it uses META-INF/services/* to load its extensions. The issue: TomEE embedded is embedded. Of course it shares its container classloader with all applications but in this case you’ll get in 90% of cases your extension as well (cause of Maven, gradle, …). So it means if you deploy your application with the desired CDI extension and another (a test one) where you don’t want them you’ll get trouble since the extension will be loaded.

How to avoid it?

Continue reading

EJBContainer, OpenEJB and single start/stop by (test) JVM


When testing a EE application you regularly rely on EJBContainer.

One issue is its lifecycle handling. Most of implementations map it (and that’s really correct) to the test lifecycle. In summary it looks like:

@BeforeClass
public static void boot() {
    container = EJBContainer.createEJBContainer();
}

@AfterClass
public static void shutdown() {
    container.close();
}

Continue reading

EJBContainer and JUnit rules, no more need of any Runner! Thanks OpenEJB!


If you read this post you surely know some “common” ways to test EE applications with JUnit using a runner. It often looks like:

@RunWith(CdiTestRunner.class)
public class MyEETestWithDeltaSpike {
    @Inject
    private ACdiBean bean;
 
    @Test
    public void theTest() {
        // do test
    }
}

or

@RunWith(EJBContainerRunner.class)
public class MyEETestWithOneOpenEJB {
    @Inject
    private ACdiBean bean;
 
    @Test
    public void theTest() {
        // do test
    }
}

These tests have something in common: they use the classpath to deploy and don’t need something else (compared to Arquillian or ApplicationComposer).

That’s great but you bind your test lifecycle to the specific runner. It means you can’t compose runners and you can’t do anything before the container bootstrap like starting a FTP server with rule-them-all or just using JUnit Theories or Parameterized runners.

Continue reading

EJBContainerRunner or test with EJBContainer easily


To test a EE application you have several solutions. One of them is to use EJBContainer.

EJBContainer container = EJBContainer.createEJBContainer(properties);
// do test
container.close();

These steps are often in a test lifecycle (@BeforeClass/@AfterClass for JUnit for instance).

With OpenEJB you also have:

container.getContext().bind("inject", this);

This allows you to get injections (@Inject, @Resource, @PersistenceContext…) in the test class.

That’s nice but you can make it easier!

Continue reading

Test a particular CDI Extension with OpenEJB ApplicationComposer


OpenEJB ApplicationComposer is an old but very efficient way to test EE code. The idea is almost the same as with ShrinkWrap and Arquillian but with a big difference: it is performance oriented and embedded only. As a quick reminder to use the ApplicationComposer (either the JUnit runner or the abstract TestNG class) you just define a test class with a set of @Module methods declaring the in memory EE model (WebApp for web.xml, Beans for beans.xml, EjbJar for openejb-jar.xml, @Classes for scanned classes…) and standard @Test methods. Of course injections work in the test class. For instance:

Continue reading

Test FTP usage?


When depending on a FTP in production we often simulate it through a
local file in dev and sometimes in preprod. That’s great and avoid to
need a big infra in all environment but make ftp dependencies optional
before the prod…so you risk to clean them and miss them in prod.

To avoid it it is easy to test FTP through JUnit using MockFtp project.

Continue reading