Resolve To Get FIT

From NeoWiki

Try FIT and JUnit for a requirements testing workout!

Andrew Glover, President, Stelligent Incorporated

28 Feb 2006

Whereas JUnit assumes that every aspect of testing is the domain of developers, the Framework for Integrated Tests (FIT) makes testing a collaboration between the business clients who write requirements and the developers who implement them. Does this mean that FIT and JUnit are competitors? Absolutely not! Code quality perfectionist Andrew Glover shows you how to combine the best of FIT and JUnit for better teamwork and effective end-to-end testing.

In the software development life-cycle, everyone owns quality. Ideally, developers start ensuring quality early in the development cycle with testing tools like Junit and TestNG, and QA teams follow up with functional system tests at the end of the cycle, using tools like Selenium. But even with excellent quality assurance, some applications are deemed low-quality upon delivery. Why? Because they don't do what they were intended to do.

Communication errors between the client or the business department that authors application requirements and the development team that implements them are a frequent cause of friction, and sometimes the cause of downright failure in development projects. Luckily, there are ways to facilitate the communication between requirements authors and implementors early on.

Contents 1 A FITting solution 2 FIT and JUnit 3 Tables FIT for testing 4 Fix it with fixtures 5 See FIT run 6 About the author

A FITting solution

The Framework for Integrated Tests (FIT) is a testing platform that facilitates communication between those who write requirements and those who turn them into executable code. With FIT, requirements are fashioned into tabular models that serve as the data model for tests written by developers. The tables themselves serve as the input and expected output for the tests.

Figure 1 shows a structured model created using FIT. The first row is the test name and the next row's three columns are headers relating to inputs (value1 and value2) and the expected results (trend()).

Figure 1. A structured model created using FIT

The nice thing is that someone who hasn't a clue how to program can write this table. FIT was designed to enable customers or business teams to collaborate earlier in the development cycle with the developers who implement their ideas. Creating simple tabular models of the application's requirements lets everyone see clearly whether code and requirements are on the same page.

Listing 1 is the FIT code that correlates to the data model in Figure 1. Don't worry too much about the details -- just note how simple the code is and that it doesn't include validation logic (i.e., assertions, etc.). You may even notice some matching variable and method names from what you saw in Table 1; more on that later.

Listing 1. Code written from the FIT model

package test.com.acme.fit.impl;

import com.acme.sedlp.trend.Trender;
import fit.ColumnFixture;

public class TrendIndicator extends ColumnFixture {
  public double value1;
  public double value2;

  public String trend(){		
    return Trender.determineTrend(value1, value2).getName();
  }
}

The code you see in Listing 1 was written by a developer who studied the table and plugged in the appropriate code. Finally, pulling everything together, the FIT framework reads the data in Table 1, calls the corresponding code, and determines the results.

FIT and JUnit

The beauty of FIT is that it enables the customer or business side of an organization to get involved in the testing process early (i.e., during development). Whereas JUnit's strength lies in unit testing during the coding process, FIT is a higher level testing tool used to determine the validity of a proposed requirements' implementation.

For example, while JUnit is adept at validating that the sum of two Money objects is the same as the sum of their two values, FIT shines in validating that the total order price is the sum of its line-item's prices minus any associated discounts. It's a subtle difference, but really important! In the JUnit example, you're dealing with specific objects (or implementations of requirements), but with FIT, you're dealing with a high-level business process.

This is significant because, usually, the people who write requirements couldn't care less about Money objects -- in fact, they may not even know such things exists! They do care, however, that when line items are added to an order, the total order price is the sum of its line items with any discounts applied.

Far from being competitive, FIT and JUnit make a great match for ensuring code quality, as you'll see in the case study further down.

Tables FIT for testing

Tables are at the heart of FIT. There are a few different types of tables (for different business scenarios), and FIT users can author tables using a variety of formats. It's possible to write tables using HTML and even Microsoft Excel, as shown in Figure 2:

Figure 2. A table written using Microsoft Excel

It's also possible to author a table using a tool like Microsoft Word and then save it in HTML format, as shown in Figure 3:

Figure 3. A table written using Microsoft Word

The code a developer writes to execute a table's data is called a fixture. To create a fixture type, you must extend the corresponding FIT fixture, which maps to the intended table. As previously mentioned, different types of tables map to different business scenarios.

Fix it with fixtures

The simplest table and fixture combination, which is most commonly utilized in FIT, is a straightforward column table, where columns map to the input and output of a desired process. The corresponding fixture type is ColumnFixture.

If you look again at Listing 1, you'll note that the TrendIndicator class extends ColumnFixture and also corresponds with Figure 3. Notice how in Figure 3, the first row's name matches the fully qualified class name (test.com.acme.fit.impl.TrendIndicator). The next row has three columns. The first two cell's values match the public instance members of the TrendIndicator class (value1 & value2) and the last cell's value matches the only method found in TrendIndicator (trend).

Now look at the trend method in Listing 1. It returns a String value. As you may have guessed by now, for each row left in the table, FIT substitutes values and compares results. In this case, there are three "data" rows, so FIT runs the TrendIndicator fixture three times. The first time, value1 is set to 84.0 and value2 is 71.2. FIT then calls the trend method and compares the value obtained from the method to that found in the table, which is "decreasing."

In this way, FIT uses the fixture code to test the Trender class, whose determineTrend method is executed each time FIT executes the trend method. When it's done testing the code, FIT generates a report like the one shown in Figure 4:

Figure 4. FIT reports the trend-test results

The green coloring of the trend column cells indicates the tests passed (i.e., FIT set value1 to 84.0 and value2 to 71.2 and received back a value of "decreasing" when trend was invoked).

See FIT run

About the author

Andrew Glover is president of Stelligent Incorporated, a JNetDirect company. Stelligent Incorporated helps companies address software quality with effective developer testing strategies and continuous integration techniques that enable teams to monitor code quality early and often. He is the coauthor of Java Testing Patterns (Wiley, September 2004).

"When you have learned to snatch the error code from the trap frame, it will be time for you to leave.", thus spake the master programmer.