JDistUnit is a Java 5 framework for distributed unit testing. It is an addition to JUnit and provides multi-host capabilities. Unlike GroboUtils or Apache JMeter (which are great tools otherwise), JDistUnit focuses on simple deployment of tests.

The project was started in September 2009 and is currently in alpha status. The latest release (version 0.1.0) was in 2009/Q4; it is fully usable, but lacks any advanced features.

Target Scenario

You have a multi-client application (e.g. a web app) that has to undergo load or stress testing. For this, you need multiple hosts to fire off requests at the same time. In your development cycle, test code changes quite often, and deploying the tests to the multiple hosts is some effort.

JDistUnit is written to help in this scenario. Your test actions are capsuled in mobile agents (using the Agentopia framework) and hot deployed onto a peer-to-peer network of multiple hosts. After execution, the agents return to your computer and performance characteristics are calculated.

System Perspective

JDistUnit system perspective

You need some spare computers on your network, on which you install and start the JDistUnit server (only once). Whenever you write a new test (as part of a mobile agent), the agent walks over to the servers, accesses the target system, and returns to your client computer (which may or may not participate in the load testing).

For a typical web app scenario, you would put e.g. the jar files from the HtmlUnit project into the JDistUnit server class path, so the agents can use the HtmlUnit commands. Remember: Your agents can only use commands that are available on the servers.

Load and Stress Testing

So what are we testing for? Two things. For both, you have a test action (e.g. "login, change user prefs, logout"), which is executed concurrently by 1000 threads on each test server, calling the target system. The question that gets answered is different depending on your focus.

JDistUnit strives to answer both questions. You specify the test action, the number of request per servers, and give it to your test server network. The answer is how many requests were successful, and what the average access time for the test action was.