Howto define jetty port for integration tests

Today I found a simple hack to define the jetty-port for a web-application integration test via command line.

The problem was the defined „default“ jetty port (here 8080) … on the build system this port was already bind … so the integration test always failed :-(.

My first idea was to call maven with external system property „jetty.port“ … (this worked already to start the web application on different ports):

mvn clean integration-test -Pintegration-test -Djetty.port=1234

The maven profile is here:

...
  <profile>
      <id>integration-test</id>
      <build>
        <defaultGoal>integration-test</defaultGoal>
        <plugins>
          <plugin>
            <artifactId>maven-surefire-plugin</artifactId>
            <executions>
              <execution>
                <id>integration-tests</id>
                <phase>integration-test</phase>
                <goals>
                  <goal>test</goal>
                </goals>
                <configuration>
                  <forkMode>once</forkMode>
                  <suiteXmlFiles>
                    <suiteXmlFile>src/test/resources/Integration-Suite.xml</suiteXmlFile>
                  </suiteXmlFiles>
                </configuration>
              </execution>
            </executions>
          </plugin>
          <plugin>
            <groupId>org.mortbay.jetty</groupId>
            <artifactId>maven-jetty-plugin</artifactId>
            <version>${jetty.version}</version>
            <executions>
              <execution>
                <id>start-jetty</id>
                <phase>pre-integration-test</phase>
                <goals>
                  <goal>run</goal>
                </goals>
                <configuration>
                  <daemon>true</daemon>
                  <connectors>
                    <connector implementation="org.mortbay.jetty.nio.SelectChannelConnector">
                      <port>${jetty.port}</port>
                    </connector>
                  </connectors>
                </configuration>
              </execution>
              <execution>
                <id>stop-jetty</id>
                <phase>post-integration-test</phase>
                <goals>
                  <goal>stop</goal>
                </goals>
              </execution>
            </executions>
          </plugin>
        </plugins>
      </build>
    </profile>

I think with this TestNG test this should work … (the base class ImportantUseCaseTest contains some @Test annotated test methods):

public class IntegrationTest extends ImportantUseCaseTest {
  @Override
  protected String getServerURL() {
    final String jettyPort = System.getProperty("jetty.port", "8080);
    return String.format("http://localhost:%s/webapp", jettyPort);
  }
}

But it doesn’t work 🙂

If I call maven with „-Djetty.port=1234“ the jetty starts on 1234 but the integration test runs on 8080.  Hmmm …

The solution was to change the surefire plugin configuration a little bit:

...
  <plugin>
     <artifactId>maven-surefire-plugin</artifactId>
     ...
     <configuration>
         ...
         <argLine>-Xmx512m -Djetty.port.integration=${jetty.port}</argLine>
     </configuration>

and the test class:

public class IntegrationTest extends ImportantUseCaseTest {
  @Override
  protected String getServerURL() {
    final String jettyPort = System.getProperty("jetty.port.integration", "8080);
    return String.format("http://localhost:%s/webapp", jettyPort);
  }
}

I guess that surefire with forkMode=once doesn’t pass the given system properties to the test jvm. Maybe with forkMode=never this problem not exists … but you can try this by yourself 😉

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 🙂