Main Page

From maven-remote-testing-plugin (inactive) Wiki
Jump to: navigation, search

Contents

Introduction

The remote-testing-plugin is used to execute tests on a remote test machine whenever the build machine can or shall not execute them.

Goals

  • remote-testing:test copies the project folder to the test machine, executes the tests and copies back the results
  • remote-testing:clean removes the project folder from the test machine

Usage

Requirements

Test machine

The test machine needs to provide zip/unzip

Basic Configuraion

The plugin makes use of the maven profile concept. You can configure it like this:

<profile>
 <id>local</id>
 <build>
  <plugins>
   <plugin>
    <groupId>org.evolvis.maven.plugins.remote-testing</groupId>
    <artifactId>remote-testing-plugin</artifactId>
    <version>x.y</version>
    <configuration>
     <testMachine>hostname or ip</testMachine>
    </configuration>
    <executions>
     <execution>
      <id>remote testing</id>
      <goals>
       <goal>clean</goal>
       <goal>test</goal>
      </goals>
     </execution>
    </executions>
   </plugin>
  </plugins>
 </build>
</profile>
<profile>
 <id>remote</id>
 <build>
  <plugins>
   <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.7.2</version>
    <configuration>
     <includes>
      <include>**/*RT.java</include>
     </includes>
    </configuration>
   </plugin>
  </plugins>
 </build>
</profile>

This will:

  • execute all tests ending in "RT.java" on the remote machine and copy back the results as soon as the maven test phase is invoked (eg. mvn -P local test).
  • tidy the remote machine on clean invokation.

Authentication

Authentication with the remote machine is achieved using username and password or username and ssh key. If you do not set a password, the plugin switches to key-auth.

Parameters

Parameter Description Required Default
goal the maven goal that is invoked on the test machine - test
pomfile the pom file that shall be executed on the test machine - pom.xml
profiles comma separated list of profiles to enable on test machine - remote
testMachine the machine on which the tests shall be ran obviously -
username the username for the remote machine - maven
password the password for the remote machine only if you do not use key-auth -
keyFile the location of the ssh private key - /home/$username/.ssh/id_rsa
keyPassphrase the passphrase of the private key only if its needed -
display the display on the testmachine that shall be used - 0
remoteFolder the folder on the remote machine we use as working directory - /tmp/remoteTesting

Things to know

Using the same test machine for different projects

This basically is a good idea as the test machine supposely is idle most of the time. Just make sure you make proper use of the remoteFolder-property as otherwise two builds ran at the same time on the same folder may crash each other.

Testing stuff requiring a display/x

If you set the display parameter to an integer it will try and connect to an existing display. If you set it to "xvfb:i", i being an integer, the plugin will launch xvfb to create the display and kill it afterwards. Requiring xvfb to be installed on the test machine, of course.

Executions

By default, the test goal is invoked on the maven lifecycle phase "process-test-classes". As the "default" plugins get executed first in each phase this effectively means we are executed just before test phase. The author does not like that. Its a workaround to make jenkins accept the test results. If you configure a phase >=test it will not do so. This behaviour has a bug entry in the tracker and related patches are offered to jenkins-ci. Therefore this may be fixed in coming releases.

Development / Project state / Condition of code

Always run mvn install/deploy on parent project to make sure you didnt make any mistakes. Otherwise the blackbox-tests will not run against the code you just wrote.

The multi-module structure was just added without adjusting the code. Earlier everything was stuffed into one single module. You may find too much coupling between the modules. Especially when it comes to properties. Feel free to optimize that / refactor some of that.

SCM and Maven repositories