Junit - How do I use a test fixture?

A test fixture is useful if you have two or more tests for a common set of objects. Using a test fixture avoids duplicating the code necessary to initialize (and cleanup) the common objects.

Tests can use the objects (variables) in a test fixture, with each test invoking different methods on objects in the fixture and asserting different expected results. Each test runs in its own test fixture to isolate tests from the changes made by other tests. That is, tests don't share the state of objects in the test fixture. Because the tests are isolated, they can be run in any order.

To create a test fixture, declare instance variables for the common objects. Initialize these objects in a public void method annotated with @Before. The JUnit framework automatically invokes any @Before methods before each test is run.

The following example shows a test fixture with a common Collection object.

package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection

Click here to View more...

JUnit 4 - Basic for Java Interview

INTO to Junit

1. @TestMark your test cases with @Test annotations. You don’t need to prefix your test cases with “test”.  In addition, your class does not need to extend from “TestCase” class.
   @Test
   public void addition() {
   assertEquals(12, simpleMath.add(7, 5));
   }
   @Test
   public void subtraction() {
   assertEquals(9, simpleMath.substract(12, 3));
   }
2. @Before and @After
   Use @Before and @After annotations for “setup” and “tearDown” methods respectively. They run before and after every test case.
   @Before
   public void runBeforeEveryTest() {
   simpleMath = new SimpleMath();
   }
   @After
   public void runAfterEveryTest() {
   simpleMath = null;
   }
3. @BeforeClass and @AfterClassUse @BeforeClass and @AfterClass annotations for class wide “setup” and “tearDown” respectively. Think them as one time setup and tearDown. They run for one time before and after all test cases.
   @BeforeClass
   public static void runBeforeClass() {
   // run for one time before all test cases
   }
   @AfterClass
   public static void runAfterClass() {
   // run for one time after all test cases
   }
4. Exception Handling
   Use “expected” paramater with @Test annotation for test cases that expect exception. Write the class name of the exception that will be thrown.
   @Test(expected = ArithmeticException.class)
   public void divisionWithException() {
   // divide by zero
   simpleMath.divide(1, 0);
   }
5. @Ignore
   Put @Ignore annotation for test cases you want to ignore. You can add a string parameter that defines the reason of ignorance if you want.
   
   @Ignore(“Not Ready to Run”)
   @Test
   public void multiplication() {
   assertEquals(15, simpleMath.multiply(3, 5));
   }
6. Timeout
   Define a timeout period in miliseconds with “timeout” parameter. The test fails when the timeout period exceeds.
   @Test(timeout = 1000)
   public void infinity() {
   while (true)
   ;
   }
7. New Assertions
   Compare arrays with new assertion methods. Two arrays are equal if they have the same length and each element is equal to the corresponding element in the other array; otherwise, they’re not.
   public static void assertEquals(Object[] expected, Object[] actual);
public static void assertEquals(String message, Object[] expected, Object[] actual);
   @Test
   public void listEquality() {
   List expected = new ArrayList();
   expected.add(5);
   List actual = new ArrayList();
   actual.add(5);
   assertEquals(expected, actual);
   }
8. JUnit4Adapter
   Run your Junit 4 tests in Junit 3 test runners with Junit4Adapter.
   public static junit.framework.Test suite() {
   return new JUnit4TestAdapter(SimpleMathTest.class);
   }

Click here to View more...

JUnit Cookbook

Here is a short cookbook showing you the steps you can follow in writing and organizing your own tests using JUnit.

Simple Test Case

How do you write testing code?

The simplest way is as an expression in a debugger. You can change debug expressions without recompiling, and you can wait to decide what to write until you have seen the running objects. You can also write test expressions as statements which print to the standard output stream. Both styles of tests are limited because they require human judgment to analyze their results. Also, they don't compose nicely- you can only execute one debug expression at a time and a program with too many print statements causes the dreaded "Scroll Blindness".

JUnit tests do not require human judgment to interpret, and it is easy to run many of them at the same time. When you need to test something, here is what you do:

1. Create a subclass of TestCase.
2. Override the method runTest()
3. When you want to check a value, call assertTrue() and pass a boolean that is true if the test succeeds

For example, to test that the sum of two Moneys with the same currency contains a value which is the sum of the values of the two Moneys, write:

public void testSimpleAdd() {
    Money m12CHF= new Money(12, "CHF");
    Money m14CHF= new Money(14, "CHF");
    Money expected= new Money(26, "CHF");
    Money result= m12CHF.add(m14CHF);
    assertTrue(expected.equals(result));
}

If you want to write a test similar to one you have already written, write a Fixture instead. When you want to run more than one test, create a Suite.

Fixture

What if you have two or more tests that operate on the same or similar sets of objects?

Tests need to run against the background of a known set of objects. This set of objects is called a test fixture. When you are writing tests you will often find that you spend more time writing the code to set up the fixture than you do in actually testing values.

To some extent, you can make writing the fixture code easier by paying careful attention to the constructors you write. However, a much bigger savings comes from sharing fixture code. Often, you will be able to use the same fixture for several different tests. Each case will send slightly different messages or parameters to the fixture and will check for different results.

When you have a common fixture, here is what you do:

1. Create a subclass of TestCase
2. Add an instance variable for each part of the fixture
3. Override setUp() to initialize the variables
4. Override tearDown() to release any permanent resources you allocated in setUp

For example, to write several test cases that want to work with different combinations of 12 Swiss Francs, 14 Swiss Francs, and 28 US Dollars, first create a fixture:

public class MoneyTest extends TestCase {
    private Money f12CHF;
    private Money f14CHF;
    private Money f28USD;
   
    protected void setUp() {
        f12CHF= new Money(12, "CHF");
        f14CHF= new Money(14, "CHF");
        f28USD= new Money(28, "USD");
    }
}

Once you have the Fixture in place, you can write as many Test Cases as you'd like.

Test Case

How do you write and invoke an individual test case when you have a Fixture?

Writing a test case without a fixture is simple- override runTest in an anonymous subclass of TestCase. You write test cases for a Fixture the same way, by making a subclass of TestCase for your set up code and then making anonymous subclasses for the individual test cases. However, after a few such tests you would notice that a large percentage of your lines of code are sacrificed to syntax.

JUnit provides a more concise way to write a test against a Fixture. Here is what you do:

1. Write a public void method in the fixture class. By convention, the name of the method begins with "test".

For example, to test the addition of a Money and a MoneyBag, write:

public void testMoneyMoneyBag() {
    // [12 CHF] + [14 CHF] + [28 USD] == {[26 CHF][28 USD]}
    Money bag[]= { f26CHF, f28USD };
    MoneyBag expected= new MoneyBag(bag);
    assertEquals(expected, f12CHF.add(f28USD.add(f14CHF)));
}

Create an instance of of MoneyTest that will run this test case like this:

new MoneyTest("testMoneyMoneyBag")

When the test is run, the name of the test is used to look up the method to run.

Once you have several tests, organize them into a Suite.

Suite

How do you run several tests at once?

As soon as you have two tests, you'll want to run them together. You could run the tests one at a time yourself, but you would quickly grow tired of that. Instead, JUnit provides an object, TestSuite which runs any number of test cases together.

For example, to run a single test case, you execute:

TestResult result= (new MoneyTest("testMoneyMoneyBag")).run();

To create a suite of two test cases and run them together, execute:

TestSuite suite= new TestSuite();
suite.addTest(new MoneyTest("testMoneyEquals"));
suite.addTest(new MoneyTest("testSimpleAdd"));
TestResult result= suite.run();

Another way is to let JUnit extract a suite from a TestCase. To do so you pass the class of your TestCase to the
TestSuite constructor.

TestSuite suite= new TestSuite(MoneyTest.class);
TestResult result= suite.run();

Use the manual way when you want a suite to only contain a subset of the test cases. Otherwise the automatic suite extraction is the preferred way. It avoids you having to update the suite creation code when you add a new test case.

TestSuites don't only have to contain TestCases. They contain any object that implements the Test interface. For example, you can create a TestSuite in your code and I can create one in mine, and we can run them together by creating a TestSuite that contains both:

TestSuite suite= new TestSuite();
suite.addTest(Kent.suite());
suite.addTest(Erich.suite());
TestResult result= suite.run();

TestRunner

How do you run your tests and collect their results?

Once you have a test suite, you'll want to run it. JUnit provides tools to define the suite to be run and to display its results. You make your suite accessible to a TestRunner tool with a static method suite that returns a test suite.
For example, to make a MoneyTest suite available to a TestRunner, add the following code to MoneyTest:

public static Test suite() {
    TestSuite suite= new TestSuite();
    suite.addTest(new MoneyTest("testMoneyEquals"));
    suite.addTest(new MoneyTest("testSimpleAdd"));
    return suite;
}

Or, as a shortcut:

public static Test suite() {
    return new TestSuite(MoneyTest.class);
}

If a TestCase class doesn't define a suite method a TestRunner will extract a suite and fill it with all the methods starting with "test".

JUnit provides both a graphical and a textual version of a TestRunner tool. Start it by typing java junit.awtui.TestRunner or junit.swingui.TestRunner. The graphical user interface presents a window with:

• a field to type in the name of a class with a suite method,
• a Run button to start the test,
• a progress indicator that turns from green to red in the case of a failed test,
• a list of failed tests.

In the case of an unsuccessful test JUnit reports the failed tests in a list at the bottom. JUnit distinguishes between failures and errors. A failure is anticipated and checked for with assertions. Errors are unanticipated problems like an ArrayIndexOutOfBoundsException. The following figure shows an example of a failed test.

You have to restart the graphical interface each time you change the code. This is tedious and time consuming. As an alternative JUnit's AWT and Swing UIs use junit.runner.LoadingTestCollector . This LoadingTestCollector reloads all your classes for each test run. This feature can be disabled by unchecking the 'Reload classes every run' checkbox. The most common JUnit problem is that many packages want to use their own class loader. Include such packages in excluded.properties. See the FAQ for details.

There is a batch interface to JUnit, also. To use it typejava junit.textui.TestRunner followed by the name of the class with a suite method at an operating system prompt. The batch interface shows the result as text output. An alternative way to invoke the batch interface is to define a main method in your TestCase class.

For example, to start the batch TestRunner for MoneyTest, write:

public static void main(String args[]) {
    junit.textui.TestRunner.run(suite());
}

With this definition of main you can run your tests by simply typing java MoneyTest at an operating system prompt.

For using either the graphical or the textual version make sure that the junit.jar file is on your CLASSPATH.

Click here to View more...