The remote-testing-plugin is used to execute tests on a remote test machine whenever the build machine can or shall not execute them.
- 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
The test machine needs to provide zip/unzip
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>
- 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 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.
|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.
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
- You can check out the sources anonymously "git clone https://evolvis.org/anonscm/git/mvn-remote-test/mvn-remote-test.git"
- The artifacts releases are deployed to: http://maven-repo.evolvis.org/releases/
- The artifacts snapshots are deployed to: http://maven-repo.evolvis.org/snapshots/