ECLIPSE IDE - JUnit Testing a Key Element Agile Software Development for JAVA (Part I)

JUnit is a unit testing framework for JAVA whose support is built-in to ECLIPSE. When implemented as part of a JAVA project in ECLIPSE it provides a fully automated means of testing all methods.

The benefit of Junit testing can be enormous for the ECLIPSE JAVA developer. Once the JUnit tests are written the process can be totally automated. It is especially useful once an application is written and deployed. Code changes and enhancements can be verified for correctness. Also, before an application is written it can be used to help create the application by developing system tests before writing any code, a process known as test driven development (TDD). Automated testing and design methodology such as that which is found in using JUint is a key element in Agile programming, where requirements and code solutions proceed as an iterative and incremental process.

There are two versions of JUnit which are supported JUnit 3 and 4. As with all software a later version number indicates a JUnit 4 is the latest version available and includes some enhancements and advantages over JUnit 3. As such, JUnit 4 is the framework that will be used to incorporate JUnit in this tutorial.

If you have been following my series of tutorials we will be working with the project which is outlined in the tutorial entitled "ECLIPSE IDE - Creating "getters" and "setters" Eliminating Tedious Programming Tasks".

The JUnit tests will be created in the workspace and project that you are working on. Since the test cases are not really useful for an end user of our project, it makes sense that we create the test cases in a separate folder. In that way they can be easily eliminated from the deployable version of the project.

To do this you select your project. The follow File > New > Source Folder, then enter a folder name (I've chose test) and click on finish. The following snapshot indicates the location of the folder.

N.B. Note "Source Folder" and not "Folder".

The test classes should be created within the same packages as the classes being tested. Thus, we need to create the test package under the test folder with the exact same name as the package where the application classes were created. In other words the test folder will mirrors the application folder. Since the name org.setterand getters tutorial was specified.

To do this select the test folder, then choose New > Package.

To create the first test select the package that has just been created under the test folder. Then step through New > JUnit > JUnit Test Case. The class which we previously created was called BillingAddess. The standard practice for naming the test is to use the class name from the package followed by the word Test.

Earlier versions of Eclipse were not as explicit as the Kepler version and would give warning messages with respect to build class inclusion of the JUnit library. If ignored when creating test case resulted in unresolved references. If you are working with one of these earlier versions of Eclipse make sure that you specify a selection of either JUnit 3 or 4. Build path errors are easily corrected and we will take up the topic of build paths in a later turtorial. For now, its sufficient to know that the build path is a way of specifying the location of external libraries which are not part of the ECLIPSE framework. JUint is an add on and must be selected for inclusion in the build path.

ECLIPSE and JUnit give you the option to select the entire class or selected members to test. In this tutorial we selected the constructor method and get setCity and setState methods for examples. These methods are selected (checked). We then click on Finish and ECLIPSE has created the test class with stubs for the methods we selected This is illustrated in the following two snapshots.

The following is a line by line analysis of the code.

Line 1: package org.GetterandSetter.tutorial;

As noted previously, the test case must be in the same package as the class to be tested. This statement does that.

Line 3: import static org.junit.Assert.*;

This makes the JUnit methods available to the program. The + sign in the margin shows that this expands to the two statements:

import static org.junit.Assert.*;

import org.junit.Test;

Line 5: public class BillingAddressTest {

The beginning of the test class.

Line 7: @Test

The @Test annotation is needed in intended identify methods intended to function as tests. This is a JUnit 4 newly defined requirement it supercedes JUnit 3 requirements regarding how tests were named. and the extends test case (i.e. creating the test case as a sub class of the framework class.

Line 8 : public void testBillingAddress() {

The beginning of the declaration for the constructor test.

Line 9: fail("Not yet implemented");

It should be obvious that there is some work needed here just by the statement wording. We'll be covering this in the next tutorial.

The code isn't ready to succeed. There is work ahead for us! But, let's jst see what happen when we run this stub program. To do that we choose fro the menu Run > Run As > JUnit Test.

The snapshot which follows shows the results of running the test in the left had view of the ECLIPSE window. The results are as expect, the code had the fail assertion for each of the three methods. The bottom of the panel displays the method "Not yet implemented".

This tutorial introduced the JUnit feature which is built-in to ECLIPSE.

We stepped through creating a folder for the unit test for the BillingAddress class introduced in a previous tutorial.

An explanation was given as to why the test code should be "segregated" from the code to be deployed.

Naming conventions for the test class was given (although in actuality this was a JUnit 3 requirement which does not exist in JUnit 4).

Methods were selected to be included in the test class.

A line by line analysis was done for the generated code.

Running the test was demonstrated.

Results were presented.

In the next tutorial, we will look at writing the test class method code. I will include as an appendix to the next tutorial the BillingAddress class code so that those just beginning with this tutorial series will be on a firm footing.