ECLIPSE IDE - "Test First Methods"- An Introduction to Test Driven Design (TDD)

The prequel to the material this tutorial will present is contained in "ECLIPSE IDE - JUnit Testing a Key Element Agile Software Development for JAVA (Part I)" and its follow on "ECLIPSE IDE - JUnit Testing a Key Element Agile Software Development for JAVA (Part II)". It would be most beneficial to review those tutorials before preceding with this one.

The benefits of Test Driven Development is that in considering first what a method is supposed to do divorces the developer from too early on becoming distracted by implementation details or obstacles. Thinking on scratch paper of what function(s) one would like a method to perform is a way to start. Then determine how the output or results could be displayed or reused by other components of the application or other applications. When this is done, methods which are more generalized and adaptable for future use result. The tests developed have an added benefit in that they portray an accurate and detailed specification of and documentation for our code.

Agile programming techniques emphasize an incremental and iterative process which tightly couples development and testing. When one implements code using the "test first" approach one is really following the Agile programming philosophy.

The test which will be constructed in this example compares the output of the method to be deployed (the actual output) with the desired output (the expected output)

To demonstrate the "test first" method we will be using the ECLIPSE toString() method.

The toString() method is inherited by all classes from the Object class. The toString() method produces a string representation of an object.

We will use the ECLIPSE scrapbook page to demonstrate this. Our example will also reinforce some previous concepts about using this valuable prototyping feature.

Let's look at the output produced by the toString() method inherited from the Object class.

The steps to perform utilizing the scrapbook are as follows;

Step 1: Create a scrapbook page called tostringexample by following the menu steps,

File > New> Other > Scrapbook page and entering the name of your project. and click on Enter. A view opens for entering statements, as we have seen in a previous tutorial. We will be using the BillingAddress class previously created The following snapshot illustrates several JAVA statements which we will execute from the scrapbook page:

• creating a new object of the class BillingAddress
• initializing several fields with there respective "setter" methods
• calling the toString() default method to display a string representtion of the object.

Step 2: Highlight the text entered. Now note the output.

Whoa!!!? !! What happened. We got "tripped up" because one important detail was forgotten. Remember, the scrapbook page is outside the package so the class BillingAddress is unknown. In previous lessons, the import statement was discussed. Our problem is corrected easily by clicking on the icon for "Sets the Import Declaration for Running Code" and following the steps to add the tutorial package to the snapshot page.

The code now can be successfully executed, but the results don't appear very useful. For this reason

The output of the toString() method inherited from the Object class is illustrated in the next snapshot. From a practical point of view this is not really very helpful. Developers will write their own version of the method. Which is what we will be doing.

We want to have a more useful toString() method? So, how is that accomplished? We rewrite our own!

When a method is created this is meant to be used rather than the method inherited from the superclass, the process is known as overriding the method.

Athough writing the new, overriding toString() method could be immediately begun, the approach taken here will demonstrate the "test first" methodology. In which we:

• consider what this new toString() method should do. That is what output would we like it to produce.
• write the test case for the new toString() method
• then, and only then, write the new toString() method
• finally test the method

The test method can naturally be added to our test cases file previously created. The code we created is as follows:

@Test
public void testToString() {
BillingAddress ba4 = new BillingAddress();
ba4.setCompanyName("Toni Styles, Inc.");
ba4.setCity("Scranton");
ba4.setState("Pennsylvania");
String testString = "Company: Toni Styles, Inc. in Scranton, Pennsylvania";
assertEquals(testString, ba4.toString());
}

It consists of:

• the @Test annotation, which helps ECLIPSE JUnit know it's a test
• the declaration of the method name, testToString with a public type
• creation of ba4, a new object of the type BillingAddress
• several set calls to ":setters'" to initialize fields
• a call to the static method assertEquals to test whether the toString() method (not yet written) satisfies the requirements.

Note that the statement:

String testString = "Company: Toni Styles, Inc. in Scranton, Pennsylvania"; actually is specification and documents for our code. It states exactly what we want the toString() method to produce.

Note also, the specification presented here will remain accurate. If the toString() method passes now and later fails in the future, the test will fail. If we want all of our tests to pass the specification in the testToString() will have to be updated, keeping the specification and documentation aspect current and accurate.

Running the JUnit test at this point results in a error since the toString() method has yet to be written.

The following code is used for the overriding toString method:

public String toString() {
return "Company: " + this.getCompanyName() + " in " + this.getCity() + ", " + this.getState();
}

Our toString() method is rather simple it involve simple text pre- and post- fixed to "getters" for the fields to be compared in the test method.

Note in the edit view for this method, a green arrow. Hovering over the arrow will give the developer "heads-up" that this is an override method.

Note also, although we could have used field names rather than "getters" in formatting the return statement, allowing our fields to remain "hidden" has advantages. If the name fields were to be replaced with a first, middle, last name set of fields, this changes would not impact this statement.

Once this code is implemented, out test runs successfully.

The error can be looked at in two ways from the JUnit test view. On the far right of the screen there are two icons for the error display. The following snapshots illustrate this.

In this tutorial, the "test first" methodology was investigated. First, the test case was created and then the actual method of built. Success and failure results were presented. New Terminology of Agile software development, Test Driven Development (TDD), method overriding were introduced.

In the next lesson we will be adding a new class to our project continuing the use of "test first" practices.