Taking JUnit Out of the Box

by Amir Shevat
07/13/2005

"Nobody likes bugs." Most articles about testing utilities start with this sentence. And it's true--we would all like our code to act exactly as we planned it to work. But like a rebellious child, when we release our code into the world it has a tendency to act as if it has a will of its own. Fortunately, unlike in parenthood, there are things we can do to make our code behave exactly as we would like.

There are many tools designed to help up test, analyze, and debug programs. One of the most well-known tools is JUnit, a framework that helps software and QA engineers test units of code. Almost everyone that encounters JUnit has a strong feeling about it: either they like it or they don't. One of the main complaints about JUnit is that it lacks the ability to test complex scenarios.

This complaint can be addressed by doing some "out of the box" thinking. This article will describe how JUnit can perform complex test scenarios by introducing Pisces, an open source JUnit extension that lets you write test suites composed of several JUnit tests, each running on a remote machine serially or in parallel. The Pisces extension will allow you to compose and run complex scenarios while coordinating all of them in a single location.

Related Reading JUnit Pocket Guide By Kent Beck

JUnit Basics

Two basic objects in JUnit are TestCase and TestSuite. The TestCase provides a set of utility methods that help run a series of tests. Methods such as setup and teardown create the test background at the beginning of every test and take it down at the end, respectively. Other utility methods do a variety of tasks, such as performing checkups while the test is running, asserting that variables are not null, comparing variables, and handling exceptions.

Developers that want to create a test case need to subclass the TestCase object, override the setup and teardown methods, and then add their own test methods while conforming to the naming convention of testTestName.

Here is what a simple TestCase subclass might look like:

public class MyTestCase extends TestCase {

    /**
    * call super constructor with a test name 
    * string argument.
    * @param testName the name of the method that 
    * should be run.
    */
    public MyTestCase(String testName){
        super(testName);
    }
    
    /**
    * called before every test
    */
    protected void setUp() throws Exception {
        initSomething();
    }
        
    /**
    * called after every test
    */
    protected void tearDown() throws Exception {
        finalizeSomething();
    }
        
    /**
    * this method tests that ...
    */
    public void testSomeTest1(){
    ...
    }
        
    /**
    * this method tests that ...
    */
    public void testSomeTest2 (){
        ...
    }
}

TestSuite is composed of several TestCases or other TestSuite objects. You can easily compose a tree of tests made out of several TestSuites that hold other tests. Tests that are added to a TestSuite run serially; a single thread executes one test after another.

ActiveTestSuite is a subclass of TestSuite. Tests that are added to an ActiveTestSuite run in parallel, with every test run on a separate thread. One way to create a test suite is to inherit TestSuite and override the static method suite().

Pages: 1, 2, 3, 4, 5

Next Page