We’re strong believers in testing of all sorts. Unit testing ensures that each of your classes and functions does what you expect, in particular at edge cases. Functional tests provide a check that entire systems work from a user point of view. Thanks to test frameworks like RSpec, JUnit, and Jasmine, unit tests are usually easy to create and run, since they depend upon nothing beyond the component being tested. While there are similar tools for creating functional tests (namely, Selenium for testing webapps), running the test can be much more complicated if you have multiple parts to your application.
At Palomino Labs, we recently completed a project that involved two main pieces: a webapp written in Rails and a data storage application in Java. In our scenario, a portion of the webapp’s functionality depended upon being able to communicate with the running Java app. In the development environment, this is a minor nuisance, requiring the developer to have the Java application running. Running the test automatically using Jenkins was a bigger problem, and since we know that automated testing is integral to catching regressions quickly, the problem needed to be solved. One option would be to have a long-running version of the Java service available to the Jenkins box, but that would far from ideal because we want to make sure that the versions of the Java and Rails projects that are used for testing stay in sync with each other. Instead, we have Jenkins start and stop a fresh, up-to-date instance of the Java service for every test run.
Adding Java Convenience
While we have scripts to run our application in the production and staging environments, we usually depend on our IDE for running the application on our development machines. This is a minor issue for developers (“Why are the tests failing? Whoops, I forgot to start that other thing…”) but a show stopper for Jenkins (née Hudson) who doesn’t want to run an IDE. The first task was to create a way to run the Java application from the command line.
Using The Exec Maven Plugin
We use Maven for building our Java projects. The Exec Maven Plugin provides an easy way to run you classes from the command line with the necessary classpath. Usage begins with including it in your pom.xml
1 2 3 4 5 6 7 8 9 10 11 12 13
Actually running a
main() method is easy—you just invoke
mvn exec:java and pass it the class you want to run:
mvn exec:java -Dexec.mainClass="com.palominolabs.widgets.Widgeter"
Start & Stop Scripts
We start by creating a set of simple process management scripts to run the Java application in the background and stop it when we’re done testing. Our project uses modules, so this script lives within the
widgeter-service module, which has the main method we want to run, at
Note the bashism
"$(cd "$(dirname "$(dirname "$0")" )"; pwd)" which finds the directory the script lives in. This script also employs lock directories, the use of which removes a race condition when using lock files.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
The stop script lives in the same directory and looks similar:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
With the Java now easy to run from the command line, we just need to wire up the Rails side of things.
We want the Widgeter to be automatically started and whenever Selenium tests (written in Cucumber & Capybara) are run—either by a developer in their IDE or by Jenkins. To do so, we edit the
cucumber script provided by the cucumber gem. The one assumption made here is that the widgets project exists at the same level as the Rails project and that this script is run from the root of the rails project.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Jenkins runs the tests using a script,
jenkins-cucumber.sh. Originially, this simply called
jenkins-build.sh which sources the project’s
bundle install, and performs migrations, before running
cucumber under xvfb. Adding lines similar to the
cucumber script above to start Widgeter before Cucumber, and stop it when the tests completed or are killed. This script is only for use by Jenkins, so we simply hardcode the location of the Widgets project.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17