Page Operations
Browse Space
Overview
Ability to distribute JUnit tests allows you to get test results from your build server 2, 3, or 5 times faster depending on amount of nodes you allocate to run your tests. You can also run your distributed JUnits directly from IDE and all IDE native JUnit integration semantics will be preserved.
Distributed Junit support is added starting GridGain 1.6.0 release. In a nutshell it simply takes your regular JUnit TestSuite and runs it in parallel on remote nodes. Even if you don't have remote nodes, the tests within your TestSuite will run in parallel on local node. Both, individual tests and test suites are supported. If you have nested test suites inside of your distributed test suite, then the whole suite will executed in parallel on remote node (note, that tests within a nested suite will still execute sequentially).
GridGain distributed JUnit support gives you the following benefits:
| Feature | Description |
|---|---|
| Minimal to Zero Code Change | Simply switch to using GridJunit3TestSuite  |
| Peer Class Loading | You don't need to explicitly deploy your tests or your code on every grid node, the deployment happens automatically. |
| Nested Test Grouping | With GridGain you have full control over how tests are grouped for parallel or remote execution by combining tests within nested test suites. |
| Customizable Test Routing | With GridGain you have full control over how every test gets routed to remote node for execution by providing your own GridTestRouter |
| Local Test Suites | Support for tests that can only be executed locally (usually due to environment issues), but still can benefit from parallel execution. |
| Configurable Test Scheduling | With GridGain you can configure how many tests can run in parallel on local or remote nodes via parallelJobsNumber configuration parameter on GridCollisionSpi |
| Native IDE integration | You can run your JUnit tests directly from any IDE, be that IDEA, Eclipse, NetBeans, etc... and your distributed tests will execute as if it was a local execution - all logging and failures will be preserved. |
Package
org.gridgain.grid.test Javadoc
Supported Implementations
You can distribute your JUnits in 2 different way. One way is to use distributed test suites for JUnit3 and JUnit4 directly, and another is to use @GridifyTest
GridGain JUnit Integration comes with support for
Please refer to corresponding JUnit integration for more information.
Bamboo Integration
When plugging JUnit3 tests into Bamboo continuous build, Bamboo may start displaying wrong test count, even though all tests do execute. This happens because Bamboo for some reason cannot properly process test class names for classes augmented by JavaAsssist which it finds in JUnit XML file from Ant.
To fix it, add the following Ant target to your Ant script after all JUnit targets. This target will go through all JUnit test XML results and remove JavaAssist suffices from test class names.
<replaceregexp byline="true"> <regexp pattern='(<testcase.*classname=\".*)(_\$\$_javassist_\d+)'/> <substitution expression='\1'/> <fileset dir="/foo/bar/test-results"> <include name="TEST-*.xml"/> </fileset> </replaceregexp>
Log4j Integration
Currently only console appenders are supported. So if you need an output file to be generated on say Bamboo we recommend you to use following Ant feature. Ant JUnit test tag has a formatter property and allows you to redirect test output to the file or files. Use it like below:
<junit ...>
<test todir="your_path" ...>
<formatter type="plain"/>
</test>
</junit>
This example will save entire test output to the "your_path" directory.
See http://ant.apache.org/manual/OptionalTasks/junit.html for additional information.