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

Our last tutorial ended with the outline of a JUnit test program having been built and the JUnit test run. Naturally as we indicated at the end of the tutorial all of the test faild because the stub program which created the tests was merely a stub and each of the three method in the JUnit test had an assert statement which presented the output message, "Not implemented yet!"

In this tutorial we will take up the the tutorial where we left off and start coding which will test the three methods:

• the testBillingAddress constructor
• the testSetCity method
• the testZipCode method

As previously mentioned, the code for the BillingAddress class is located in the Appendix section at the end of the tutorial.

So let's begin!

,

If you have been following along and coding when you restart ECLIPSE you should see the test code displayed as indicated in the preceding snapshot. If you have been exploring features on your own, the window may appear differently. In that case, go to Window>Open Perspecitive > Java Perspective. If necessary, use the Project Explorer to open the test program.

Now we will begin coding the BillingAddress constructor test method. So let's see what the constructor was supposed to do.

// constructor

public BillingAddress() {
companyName = "blank";
streetAddress = "blank";
city = "blank";
state = "blank";
zipCode = 00000;
}

The constructor has 5 fields. Four of them are set to the word blank, and the fifth, the zipCode is set to zeros.

So, our steps are as follows:

• Create a new BillingAddress object
• Test that the fields of the object are set correctly.

The first line we have seen before:

BillingAddress ba1 = new BillingAddress();

The next line is a new one. The assertEquals method is a new one. It is part of the JUnit test package. The values provided to the method are expected value and the actual value. In this case the expected value, the value set in the constructor was the word blank.For the actual value we obtain it by utilizing the getBillingAddress method with respect to the object ba1.

To reiterate this point, the template for assertEquals is:

assertEquals(expected value, actual value);

and our statement becomes:

assertEquals("blank",ba1.getCompanyName());

This statement is repeated for the next three fields of the BillingAddress, ba1, substituting the appropriate "getter" for each.

The last statement of the test case is slightly different in that the field zipCode is an integer.

There is a difference between the assertEquals and method we have observed thus far.

In the case of the getCity method we had to do the following

• we had to create an object of the type BillingAddress, and
• refer to the method quaified by the created opject name as ba1.getCity();.

Why don't we have?

BillingAddressTest bat = new BillingAddressTest();

bat.assertEquals(......

This is because assertEquals is a static method.

A static method is:

• a method which belongs to the class as a whole.
• doesn't belong to an instance of the class, doesn't belong to an object
• the syntax is class.method.
• if we are using it in the class it belongs to the class prefix can be omitted.

Note also, ECLIPSE assists the developer by displaying the text of a static method in italics.

To better see this hover over one of the assert statements and see what ECLIPSE know the qualification of the method is. (See the following snapshot.)

The BillingAddressTest can now be run for the BillingAddress constructor. The following snapshot illustrates the result. The test passed. The remaining two tests case for the setCity and setState will be completed next.

We complete the test cases for setCity and setState each in a similar fashion. In each case, we create a BillingAddress object and then call the assertEquals method with the the value each was set with for the expected and invoke the appropriate get method to retrieve the actual.value.

We now rerun the tests and, Success! Note the green bar replaces the bark colored bar which was displayed when there were failures.

Suppose something went wrong with a test, what information could we get to help us solve the problem?

Let's create an error in the second test. Make a typo in the expected value for "Scranton" by spelling it "Scrantno" and see what happens.

From the test results view, highlight the second test, the one which failed and maximize the failure trace part of the JUnit test results view. The text reports what is wrong. There are two icons in the upper right hand corner of this part of the view which show alternative ways of look at the error. These two ways are illustrated in the snapshots below.

In this tutorial we completed the test case for the methods we selected when we created the "stub" test program in the previous tutorial. The fail method (which is also a static method of the JUnit software is replaced by appropriate get and set methods as the test case may require. We ran the tests and noted the success of the tests once appropriate code was added. We also looked at two ways to look at the output of a failure in a test.

In the tutorial we just completed, the methods to be tested had already been built. In the next tutorial we will look at the case of specifying the test and then creating the method which will produce the desired output. This will be our first look at the "test first" approach and our introduction to Test Driven Development (TDD).