Concept to handle minimal and maximal tests in a maven project

In real world applications we have all too often external dependencies in test cases. Sometimes theses third party are not always available (i.e. remote webservices).

For continuous integration I want check a minimal set of tests but for my local development i want check a maximal set of tests. I want run my tests on command line (via maven) and in eclipse (via testng-plugin).

Here is my idea to do that …

My project super pom defines 2 profiles:

• test-min
  1. active by default
  2. exclude testng groups (online-tests, thirdparty-tests,…)
• test-max
  1. run a defined testng suite
  2. the suite defines a maximal set of test (all testng groups)

<profiles>
  <profile>
    <id>test-min</id>
    <activation>
      <activeByDefault>true</activeByDefault>
    </activation>
    <build>
      <plugins>
        <plugin>
          <artifactId>maven-surefire-plugin</artifactId>
          <inherited>true</inherited>
          <configuration>
            <excludedGroups>${excludedTestGroups}</excludedGroups>
          </configuration>
        </plugin>
      </plugins>
    </build>
  </profile>
  <profile>
    <id>test-max</id>
    <build>
      <plugins>
        <plugin>
          <artifactId>maven-surefire-plugin</artifactId>
          <inherited>true</inherited>
          <configuration>
            <suiteXmlFiles>
              ${basedir}/src/test/resources/Testsuite.xml
            </suiteXmlFiles>
          </configuration>
        </plugin>
      </plugins>
    </build>
  </profile>
</profiles>
<properties>
  <excludedTestGroups>online,integration,thirdparty</excludedTestGroups>
</properties>

Each subproject must define a testng src/test/resources/Testsuite.xml:

<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">
<suite name="TestSuite for Foobar">
  <test name="Online Tests">
    <packages>
      <package name="de.foobar.*" />
    </packages>
    <groups>
      <run>
        <include name="online" />
      </run>
    </groups>
  </test>
  <test name="Integration Tests">
    <packages>
      <package name="de.foobar.*" />
    </packages>
    <groups>
      <run>
        <include name="integration" />
      </run>
    </groups>
  </test>
  <test name="Thirdparty Tests">
    <packages>
      <package name="de.foobar.*" />
    </packages>
    <groups>
      <run>
        <include name="thirdparty" />
      </run>
    </groups>
  </test>
  <!-- Each project can define MORE groups: i.e. "interactive" -->
  <test name="Other Tests">
    <packages>
      <package name="de.foobar.*" />
    </packages>
    <groups>
      <run>
        <exclude name="online" />
        <exclude name="integration" />
        <exclude name="thirdparty" />
        <!-- Each project can define MORE groups: i.e. "interactive" -->
      </run>
    </groups>
  </test>
</suite>

If the sub project defines more exclude groups (i.e. a additional “interactive” group) then the pom must overwrite the excludedTestGroups property:

<properties>
  <excludedTestGroups>online,integration,thirdparty,interactive</excludedTestGroups>
</properties>

To check the correct configuration of the two profiles we can use help:effective-pom:

mvn -Ptest-min help:effective-pom | less

<plugin>
  <artifactId>maven-surefire-plugin</artifactId>
  <configuration>
    <excludedGroups>online,integration,thirdparty,interactive</excludedGroups>
  </configuration>
</plugin>

mvn -Ptest-max help:effective-pom | less

<plugin>
  <artifactId>maven-surefire-plugin</artifactId>
  <configuration>
    <suiteXmlFiles>
      <suiteXmlFile>d:\foobar\src/test/resources/Testsuite.xml</suiteXmlFile>
    </suiteXmlFiles>
  </configuration>
</plugin>

Now I can run min/max tests for each project which depend on the above super-pom. The test-min is the default profile and would be used on the continuous integration system (i.e. TeamCity).

Try it

My Eclipse Plugin List

Today i updated my Eclipse 3.5 M7 to the final 3.5. Here are my plugin list:

• PropEdit – nice Propertyeditor which can handle UTF-8 correctly
• Spring-IDE – Beansearch, Contexteditor with content assistant
• FindBugs - Check your code for bugs
• WTP – of course for a web developer
• Subversive – for SVN integration
• JBoss Tools – nice XHTML (facelets) editor, web.xml editor, faces-config editor and more
• m2Eclipse – cool maven integration
• EclEmma – code coverage
• TeamCity – continues integration platform
• MoreUnit – jump from Code to Unittest, create new Test if not exists
• TestNG – integration for these unittests

What are your prefered plugins?

Using Session/Request-Scoped SpringBeans in TestNG

Today i will show you how to use spring-beans (especially session-scoped respectively request-scoped) in Unittests.

First of all … its easy to use a singleton bean (no scope) in a unit-test, load the ClassPathXmlApplicationContext with configLocations, use getBean(“name”) and then use the returned objects.

But if you want use a enhanced (J2EE) spring-configuration in your unit-test you have to use the XmlWebApplicationContext.

Lets use a simple example! Imagine you have different context-files, e.g. spring-beans-application.xml:

  <bean id="Foobar1" class="de.ahoehma.test.Foobar" scope="request"/>
  <bean id="Foobar2" class="de.ahoehma.test.Foobar" scope="session"/>
  <bean id="Foobar3" class="de.ahoehma.test.Foobar" />

Then you have your unit-test:

public class SpringBeansTestNg {

  //
  // XXX we have to define all spring-context-files - later this could be done via test-ng-provider or
  //     via spring with "spring-beans-*.xml" (i try it but it doesnt work)
  //
  private final String[] contextLocations = new String[]{
      "spring-beans-application.xml",
      "spring-beans-services.xml",
      "spring-beans-persistence.xml",
      "spring-beans-security.xml",};

  private ApplicationContext applicationContext;

  @BeforeTest
  private void loadApplicationContext() {
    final XmlWebApplicationContext xmlApplicationContext = new XmlWebApplicationContext();
    xmlApplicationContext.setConfigLocations(contextLocations);
    final MockServletContext servletContext = new MockServletContext("");
    xmlApplicationContext.setServletContext(servletContext);
    final RequestContextListener requestContextListener = new RequestContextListener();
    final MockHttpServletRequest request = new MockHttpServletRequest(servletContext);
    final ServletRequestEvent requestEvent = new ServletRequestEvent(servletContext, request);
    requestContextListener.requestInitialized(requestEvent);
    xmlApplicationContext.refresh();
    applicationContext = xmlApplicationContext;
  }

  /**
   * @return request scoped bean
   */
  private Foobar getFoobar1() {
    return (Foobar) applicationContext.getBean("Foobar1"); //$NON-NLS-1$
  }

 /**
   * @return session scoped bean
   */
  private Foobar getFoobar2() {
    return (Foobar) applicationContext.getBean("Foobar2"); //$NON-NLS-1$
  }

 /**
   * @return singleton bean
   */
  private Foobar getFoobar3() {
    return (Foobar) applicationContext.getBean("Foobar3"); //$NON-NLS-1$
  }
}

The magic happend in the loadApplicationContext.

Try it