CSC/ECE 517 Fall 2009/wiki1a 1 JunitTest

Writing Effective JUnit Test Cases
----------------------------------------------------

JUnit is a testing framework aimed at making unit testing easy by simplifying the writing of test cases and by providing automated running of tests and test suites.

The main aim of this document is to provide a repository of rules that can be used in-order to write an effective Junit test. This doc also discusses various sites and suggest which are the best sites to read for an overview of the topic and to understand the different philosophies of test-case design.

Introduction

Unit Testing Overview

The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect.

Test Case
It describes a scenario that can be exercised through the application.
Each test case is divided into two parts: input and expected output.
The input part lists all the test case statements that create variables or assign values to variables.
The expected output part indicates the expected results; it shows either assertions or the message 'no exception' (when no assertions exist).

The main issue in constructing a unit test is deciding the scope of test cases.
If the scope is too narrow, then the tests will be trivial and the objects might pass the tests, but there will be no design of their interactions and interactions of objects are important for object oriented design.
On the other hand if the scope is too broad, then there is a high chance that not every component of the new code will get tested.
The programmer is then reduced to testing-by-poking-around, which is not an effective test strategy.

Junit Overview

Normal testing is usually like this:
1. An expression is used 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.
2. Expressions are tested as statements which print to the standard output stream.

But its not preferred because:

  1. They require human judgment to analyze their results.

  2. They are cumbersome, non repeatable - you can only execute one debug expression at a time and 

     a program with too many print statements causes the dreaded "Scroll Blindness".

On the upper hand, 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. Annotate a method with @org.junit.Test

  2. When you want to check a value, import org.junit.Assert.* statically, call assertTrue() and pass a boolean that is true if 
     the test succeeds

So JUnit is a open-source unit testing framework for Java and provides a way to organize test data and perform repeatable test execution.
In JUnit, one has to write Java code, called a test class, that describes test data, invokes the methods to be tested, and determines test results.

JUnit was originally written by Erich Gamma and Kent Beck.
The official JUnit home page is http://junit.org.
JUnit is Open Source Software, released under IBM's Common Public License Version 0.5 and hosted on SourceForge.

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

JUnit mailing lists and forums

JUnit user list JUnit announcements JUnit developer list

JUnit documentation

   * JUnit Test Infected: Programmers Love Writing Tests
   * JUnit Cookbook
   * JUnit - A Cook's Tour
   * JUnit FAQ 

JUnit testing costs some time and money, but unit testing provides some undeniable advantages. It allows for automation of the testing process, reduces difficulties of discovering errors contained in more complex pieces of the application, and test coverage is often enhanced because attention is given to each unit.

For example, if you have two units and decide it would be more cost effective to glue them together and initially test them as an integrated unit, an error could occur in a variety of places:

   * Is the error due to a defect in unit 1?
   * Is the error due to a defect in unit 2?
   * Is the error due to defects in both units?
   * Is the error due to a defect in the interface between the units?
   * Is the error due to a defect in the test?

Finding the error (or errors) in the integrated module is much more complicated than first isolating the units, testing each, then integrating them and testing the whole. [2]