Best Practices with Junit

This section suggest you about Best Practices with Junit.

Best Practices with JUnit

• Do not use the test-case constructor to set up a test case.

Setting up a test case in the constructor is not a good idea. Consider the following code :

package devmanuals.junit;

import java.util.ArrayList;
import org.junit.Test;
import java.util.*;

public class SomeTest {
@Test(expected = IndexOutOfBoundsException.class)
public SomeTest(String testName) {
super();
new ArrayList<Object>().get(1);
}
}

This will show you the following error :

• Don't assume the order in which tests within a test case run.

You should not assume that tests will be called in any particular order. Consider the following code segment :

public class SomeTestCase{
public SomeTestCase () {
}
@Test
public void testDoThisFirst () {
}
@Test
public void testDoThisSecond () {
}
}

In this example, it is not certain that JUnit will run these tests in any specific order when using reflection. Running the tests on different platforms and Java VMs may therefore yield different results, unless your tests are designed to run in any order.

• Avoid writing test cases with side effects.

         Test cases that have side effects exhibit two problems:

        1. They can affect data that other test cases rely upon

        2. You cannot repeat tests without manual intervention.

• Call a super class's setUp()/tearDown() or @Before/ @After methods when sub-classing.

         You can call 'super class' setup method as ' super.setUp()' or @Before method as 'super.Methodname '.

• Do not load data from hard-coded locations on a filesystem.

          Tests often need to load data from some location in the filesystem.Consider the following :

public void setUp () { 
FileInputStream inp ("C:\\TestData\\dataSet1.dat");
}

The code above relies on the data set being in the C:\TestData path.

That assumption is incorrect in two situations:

1.A tester does not have room to store the test data on C: and stores it on another disk

2.The tests run on another platform, such as Unix

One solution might be :

public void setUp () {
FileInputStream inp ("dataSet1.dat");
}

• Keep tests in the same location as the source code.

If the test source is kept in the same location as the tested classes, both test and class will compile during a build. This forces you to keep the tests and classes synchronized during development. Indeed, unit tests not considered part of the normal build quickly become dated and useless.

• Name tests properly.

Name tests properly. For example, the test case for the class MessageLog should be TestMessageLog. That makes it simple to work
out what class a test case tests. Test methods' names within the test case should describe what they test.

• Ensure that tests are time-independent.

Where possible, avoid using data that may expire; such data should be either manually or pro grammatically refreshed.

• Consider locale when writing tests.

Consider a test that uses dates. One approach to creating dates would be :

Date date = DateFormat.getInstance ().parse ("dd/mm/yyyy");

Unfortunately, that code doesn't work on a machine with a different locale. Therefore, it would be far better to write :

Calendar cal = Calendar.getInstance ();
Cal.set (yyyy, mm-1, dd);
Date date = Calendar.getTime ();

The second approach is far more resilient to locale changes.

• Use the wide variety of assert methods to express your intention in a simpler fashion. Instead of writing :

          assert (creds == 3);

         Write :

         assertEquals ("The number of credentials should be 3", 3, creds);

The above example is much more useful to a code reader. And if the assertion fails, it provides the tester with more information.

• Swing

When testing a Swing-based UI, you can write tests to ensure that : All the components reside in the correct panels. You've configured the layout managers correctly. Text widgets have the correct fonts.

• XML

When testing classes that process XML, it pays to write a routine that compares two XML DOMs for equality. You can then pro grammatically define the correct DOM in advance and compare it with the actual output from your processing methods.

• Servlet

With servlets, a couple of approaches can work. You can write a dummy servlet framework and preconfigure it during a test. The framework must contain derivations of classes found in the normal servlet environment. These derivations should allow you topreconfigure their responses to method calls from the servlet. For example:

     1. HttpServletRequest can be sub-classed to allow the test class to specify the header, method, path info, and other data

     2. HttpServletResponse can be sub-classed to return an output stream that stores the servlets' responses in a string for later checking.

• Build a test case for the entire system

It is important to build a test case for the entire system. If one test case exercises the whole system, then developers can test the impact their changes will have on every class in the system. This increases the chance of errors resulting from unanticipated side effects being caught earlier. Without a universal test case, developers tend to test only the class they have modified. Also, running all the tests for the system becomes a painstaking manual process.