Testing

Revision as of 17:14, 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) {
    // Scans classpath for exploded or unexploded jars.
    ResinBeanContainer resin = new ResinBeanContainer();

    // Optional, is overriding default descriptor locations.
    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");

    resin.start(); // Detect currently running instances.

    AccountService accountService = resin.lookup(AccountService.class);

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

In the example above, we should add the capability to programmatically provide XML deployment descriptors to be used. This will enable developers provide test specific descriptors when needed (like test databases, mock objects, etc). By default, the embedded container can look for the default locations for descriptors in the classpath (e.g. META-INF/ejb-jar.xml, WEB-INF/ejb-jar.xml, META-INF/persistence.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.