Schlagwörter: TestNG Kommentarverlauf ein-/ausschalten | Tastaturkürzel

  • Andreas Höhmann 12:05 am Tuesday, 1. June 2010 Permalink |
    Tags: integration-test, , maven2, port already bind, , TestNG   

    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 😉

    Advertisements
     
  • Andreas Höhmann 15:03 am Thursday, 26. November 2009 Permalink |
    Tags: , , , , TestNG   

    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 🙂

     
    • Thomas Wabner 10:09 am Dienstag, 31. Januar 2012 Permalink | Zum Antworten anmelden

      Short info … the current 2.11 version of the surefire plugin contains a bug with the „excludeGroups“ rule … you need to wait for 2.12 or just use 2.10.

  • Andreas Höhmann 18:50 am Wednesday, 22. July 2009 Permalink |
    Tags: EclEmma, , FindBugs, JBoss Tools, , MoreUnit, , PropEdit, Spring-IDE, TestNG, WTP   

    My Eclipse Plugin List 

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

    eclipse3.5

    • 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?

     
  • Andreas Höhmann 17:18 am Wednesday, 15. October 2008 Permalink |
    Tags: request, scope, session, singleton, , test, TestNG, unit   

    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 🙂

     
c
Neuen Beitrag erstellen
j
nächster Beitrag/nächster Kommentar
k
vorheriger Beitrag/vorheriger Kommentar
r
Antworten
e
Bearbeiten
o
zeige/verstecke Kommentare
t
Zum Anfang gehen
l
zum Login
h
Zeige/Verberge Hilfe
Shift + ESC
Abbrechen