Search This Blog

Subscribe:

Thursday, August 26, 2010

Become JUnit expert from installation to examples

JUnit

JUnit is a simple, open source framework to write and run repeatable tests. It is an instance of the xUnit architecture for unit testing frameworks.

JUnit features include:

    • Assertions for testing expected results
    • Test fixtures for sharing common test data
    • Test runners for running tests.

Download JUnit: The latest version of JUnit is available on SourceForge.

Install: To install JUnit on Windows, Unzip the junit.zip distribution file to a directory referred to as %JUNIT_HOME%. Add JUnit to the classpath:

set CLASSPATH=%CLASSPATH%;%JUNIT_HOME%\junit.jar

For Unix (bash) Unzip the junit.zip distribution file to a directory referred to as $JUNIT_HOME. Add JUnit to the classpath:

export CLASSPATH=$CLASSPATH:$JUNIT_HOME/junit.jar

while using eclipse u just need to add the external jar file to your project.

Easy way to set ClassPath: Add JUnit jar file to Path variable. To add jar file, go to my computer, right click, properties, environment variables, add jar file location to class path user variable.

Variable Values

CLASSPATH ------ E:\junit-4.8.2.jar;


Framework of JUnit

frameworkStructure:

l setUp(): Storing the fixture's objects in instance variables of your TestCase subclass and initialize them by overriding the setUp method

l tearDown(): Releasing the fixture’s

l testCase() :Defining how to run a test suite.

Writing our tests: Step by Step procedure

Create a class:

import org.junit.*;

import static org.junit.Assert.*;

import java.util.*;

public class SimpleTest {

Write a test method (annotated with @Test) that asserts expected results on the object under test

@Test

public void testEmptyCollection() {

Collection collection = new ArrayList();

assertTrue(collection.isEmpty());

}

If you are running your JUnit 4 tests with a JUnit 3.x runner, write a suite() method that uses the JUnit4TestAdapter class to create a suite containing all of your test methods:

public static junit.framework.Test suite() {

return new junit.framework.JUnit4TestAdapter(SimpleTest.class);

}

Although writing a main() method to run the test is much less important with the advent of IDE runners, it's still possible:

public static void main(String args[]) {

org.junit.runner.JUnitCore.main("junitfaq.SimpleTest");

}

}

Run the test:

To run the test from the console, type:

java org.junit.runner.JUnitCore junitfaq.SimpleTest .

To run the test with the test runner used in main(), type:

java junitfaq.SimpleTest

The passing test results in the following textual output:

Time: 0

OK (1 tests)

]

Text 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 collection;

@Before

public void setUp() {

collection = new ArrayList();

}

@Test

public void testEmptyCollection() {

assertTrue(collection.isEmpty());

}

@Test

public void testOneItemCollection() {

collection.add("itemA");

assertEquals(1, collection.size());

}

}

Given this test, the methods might execute in the following order:

setUp()

testEmptyCollection()

setUp()

testOneItemCollection()

The ordering of test-method invocations is not guaranteed, so testOneItemCollection() might be executed before testEmptyCollection(). But it doesn't matter, because each method gets its own instance of the collection.

Although JUnit provides a new instance of the fixture objects for each test method, if you allocate any external resources in a @Before method, you should release them after the test runs by annotating a method with @After. The JUnit framework automatically invokes any @After methods after each test is run. For example:

package junitfaq;

import org.junit.*;

import static org.junit.Assert.*;

import java.io.*;

public class OutputTest {

private File output;

@Before

public void createOutputFile() {

output = new File(...);

}

@After

public void deleteOutputFile() {

output.delete();

}

@Test

public void testSomethingWithFile() {

...

}

}

With this test, the methods will execute in the following order:

createOutputFile()

testSomethingWithFile()

deleteOutputFile()

Testing a method which doesn’t return anything: Often if a method doesn't return a value, it will have some side effect. Actually, if it doesn't return a value AND doesn't have a side effect, it isn't doing anything.

There may be a way to verify that the side effect actually occurred as expected. For example, consider the add() method in the Collection classes. There are ways of verifying that the side effect happened (i.e. the object was added). You can check the size and assert that it is what is expected:

@Test

public void testCollectionAdd() {

Collection collection = new ArrayList();

assertEquals(0, collection.size());

collection.add("itemA");

assertEquals(1, collection.size());

collection.add("itemB");

assertEquals(2, collection.size());

}

Another approach is to make use of MockObjects.

A related issue is to design for testing. For example, if you have a method that is meant to output to a file, don't pass in a filename, or even a FileWriter. Instead, pass in a Writer. That way you can pass in a StringWriter to capture the output for testing purposes. Then you can add a method (e.g. writeToFileNamed(String filename)) to encapsulate the FileWriter creation.

Writing a test that passes when an expected exception is thrown: Add the optional expected attribute to the @Test annotation. The following is an example test that passes when the expected IndexOutOfBoundsException is raised:

@Test(expected=IndexOutOfBoundsException.class)

public void testIndexOutOfBoundsException() {

ArrayList emptyList = new ArrayList();

Object o = emptyList.get(0);

}

Writing a test that fails when an unexpected exception is thrown:

Declare the exception in the throws clause of the test method and don't catch the exception within the test method. Uncaught exceptions will cause the test to fail with an error.

The following is an example test that fails when the IndexOutOfBoundsException is raised:

@Test

public void testIndexOutOfBoundsExceptionNotRaised()

throws IndexOutOfBoundsException {

ArrayList emptyList = new ArrayList();

Object o = emptyList.get(0);

}

Where to keep our programs:You can place your tests in the same package and directory as the classes under test.

For example:

src

com

xyz

SomeClass.java

SomeClassTest.java



For more info,check blogs of http://www.mpowerglobal.com