ECLIPSE IDE - Tutorial Adding a Class to the Package After Creating the Test

Chipmunk had decided to start a car rental agency. He went around town and created a relationship with a number of potential clients. Since he was eager to make some money, he started out creating his BillingAddress class first. He thought he would use it for advertising as well when he was ready to go public. He had enough interest from potential customers that he went out and bought lots of cars, but only one of each model. (This fact will become important later.)

Now, he needs to have a Car class added to his application. The developer he hired believes in the "test first" methodology and has proposed creating the test method, testCar, first. Chipmunk is skeptical but he said, "Go ahead!".

In this tutorial we'll see how it went.

To create the CarTest JUnit test, one first selects the package in the project root folder and right clicks on New > JUnit test. When the menu for the new JUnit test appears we enter the name, CarTest. The "Class under test field:" is left blank as no class is associated with this test as of yet. .Click on Finish. and the new test case is created. These actions are illustrated in the following snapshots.

The test case coding is rather simple. We create a new object of the Car class and create calls to the static method assertEquals for the car model, model year, and the name of the car manufacturer.

There are several things to note in this example. First, the constructor initializes the model field; and secondly, notice that the indicates all of the assignment statements are flagged with errors. Finally notice that in the assertEquals method calls we use field names than the get calls as used when we created the AddressBilling test class.

Although we have errors in the test, ECLIPSE will still allow it to be run. The test is run by selecting Run> JUnit Test. A warning popup appears, click on Proceed.

Not surprisingly, the test fails. If you look at the messages, ECLIPSE reported that "Car cannot be resolved to a type". This just means that there is no Car class that ECLIPSE know about, we have not created it yet.

If you hover over the word car in the source. ECLIPSE has a number of suggestions for how to fix the proble. This "quick fix" assistance can help to resolve most problems although at time ECLIPSE is baffled as to what to do and will just report a message, "No suggestions".

In this case, we know that the problem is that the class does not exist, so we just double click an the option and the ECLIPSE window to create a new class opens automatically. When ECLIPSE proposes a "quick fix", sometimes there some sort of subtle problem with the proposed fix. In this case there is such a problem. ECLIPSE proposed creating a class (this is great) but the destination indicated is to create the class in the test folder. This is NOT what we want. We want the the class to be created in our src folder. Easily corrected, but it serves a good example that one should look over any "quick fix" suggestion content.

All we need to do is Browse and click on src. ECLIPSE then proceed to create the Car class "stub". as illustrated below.

Looking at CarTest.java we see a number of errors. In each case we will let ECLIPSE "quick fix" help us to resolve them.

Hovering over the line:

Car c1 = new Car("sunfire");

ECLIPSE has two suggestions. The appropriate one is to create the constructor method, which ECLIPSE proceeds to do and opens the view to that source.

Not that if we do not perform a save on Car.java at this point when we return to CarTest.java, the error persists. Thus, when correcting errors always remember to perform a save for any suggested code change at that point. It helps to prevent any confusion. If the code change had a side effect resulting in an error you would know that the code change save had some adverse effect. Associating the suggested code change with the side effect might help you resolve the resulting problem.

The following three statements:

assertEquals("Sunfire",c1.model);
assertEquals(2006,c1.modelYear);
assertEquals("Pontiac",c1.manufacturer);

are resolved by hovering over them. The ECLIPSE "quick fix" suggestions differ, but the appropriate action of creating fields is the same. Note that the field type should be set to String or int ih these cases.

The snapshots which follow indicate our process through the error messages.

This tutorial featured the "test first" method. A test case was developed before the class was written.

ECLIPSE we observed can do a great deal in helping in this "code on the go approach".After specifying our field requirements and expected results, ECLIPSE through its quick fix suggestions helped us move from a test case with no associated class. To the complete class definition and have a successful test run.

As for what's next. There are several minor points that it seem a good idea to defer discussion on which we will address in the next tutorial which will focus on the relationship between classes based on a common field.