Testing

Revision as of 20:58, 4 January 2011

CanDI/Bean Container Testing Support

CanDI/Bean Container based testing is supported in two forms. The first mechanism is a low level bean container API that can be used in any Java SE environment including a command line application. The second form is a high-level annotation based API to integrate with JUnit 4. In both cases, the bean container scans for and deploys exploded and unexploded modules in the classpath and/or file system.

The simple bootstrap API for Java SE environments is useful for newcomers to Resin as well as people who not use any test frameworks for testing. The following is example code for the Java SE API:

public class AccountServiceTest {

  public static void main (String[] arguments) {
    ResinBeanContainer resin = new ResinBeanContainer();

    // Should be possible to add or specify file-system based modules instead of class-path 
    // scanning. This is needed for Arquillian.
    // resin.addModule("test1.jar", "test2.jar");
    // Optional, is overriding default descriptor locations for testing.
    resin.addBeanXML("beans-test-1.xml, beans-test-2.xml");
    resin.addEjbJarXML("ejb-jar-test-1.xml, ejb-jar-test-2.xml");      
    resin.addPersistenceXML(
      "persistence-test-1.xml, persistence-test-2.xml");

    // Scans and deploys exploded or unexploded jars.
    resin.start(); // Detect currently running instances.

    // Substitute for injection - could also support getting the JNDI context.
    AccountService accountService = resin.lookup(AccountService.class);

    resin.close(); // Optional.
  }
}

In the example above, the capability to programmatically specify XML deployment descriptors enables developers to use test specific descriptors when needed (like test databases, mock objects, etc). By default, the bean container will look for the default locations for descriptors (e.g. META-INF/ejb-jar.xml, WEB-INF/ejb-jar.xml, META-INF/persistence.xml, META-INF/beans.xml etc). The start method should start the embedded container if it is not already running. This optimization would be useful while running a suite of tests. Lookup methods could be used to get reference to deployed components. The close method would shut-down an embedded container instance. It should be optional and only needed in the case where it is necessary to open and close containers in the same process. This essentially mirrors what is needed for the embeddable container API in EJB 3.1 Lite.

We can build on the basic Java SE based functionality and provide JUnit and TestNG specific support as below:

@RunWith(ResinJUnitRunner.class)
@TestConfiguration(beanXML="beans-test.xml",
                   ejbJar="ejb-jar-test.xml",   
                   persistenceXml="persistence-test.xml")
public class AccountServiveTest {

  @Inject
  private AccountService accountService;

  @Test
  public void testGetAccount() throws Exception {
    Account account = accountService.getAccount(1007);
    assertNotNull(account);
  }
}

The JUnit/TestNG specific API can perform injection into the JUnit/TestNG class itself as well as manage the container life-cycle behind the scenes. This support mirrors what is provided for Spring testing support.

Building on the basic functionality, we can also put in integrated support for both EasyMock/JMock and DBUnit. For example, we could automatically mock all dependent objects and perform automatic DBUnit setup against any configured database. The following could also be useful:

1. Support explicitly listing files in the test so that only those files are loaded.
2. Excluding files from the test based on regular expressions patterns.
3. Allow selective disabling of Resin functionality for faster startup and shutdown.