Testcase Class

The book has now been published and the content of this chapter has likely changed substanstially.
Please see page 373 of xUnit Test Patterns for the latest information.
Also known as: Test Fixture

Where do we put our test code?

Group a set of related Test Methods on a single Testcase Class.

Sketch Testcase Class embedded from Testcase Class.gif

We put our test logic into Test Methods (page X) but Test Methods needs to be associated with a class. A Testcase Class gives us a place to host those methods that we can later turn into Testcase Objects (page X).

How It Works

We collect all the Test Methods that are related in some way onto a special kind of class, the Testcase Class. At runtime, the Testcase Class acts as a Test Suite Factory (see Test Enumeration on page X) that creates a Testcase Object for each Test Method and add them to a Test Suite Object (page X) that the Test Runner (page X) will use to run them all.

Why We Do This

In object-oriented languages, we prefer to put our Test Methods onto a class rather than having them as global functions or procedures (even if that is allowed.) By making them instance methods of a Testcase Class we can create a Testcase Object for each test by instantiating the Testcase Class once for each Test Method. This allows us to manipulate the Test Methods at runtime.

We could, of course, implement each Test Method on a separate class but that creates additional overhead and clutters the class name space. It also makes it harder (though not impossible) to reuse functionality between tests.

Implementation Notes

Most of the complexity of writing tests involves how to write the Test Methods; what to include inline and what to factor out into Test Utility Methods (page X), how to Isolate the SUT (see Principles of Test Automation on page X), and so on.

The real magic associated with the Testcase Class occurs at runtime and is described in Testcase Object and Test Runner. As far as we are concerned, all we have to do is write some Test Methods that contain our test logic and let the Test Runner do its magic. We can avoid Test Code Duplication (page X) by using Extract Method[Fowler] refactoring to factor out common code into Test Utility Methods. These can be left on the Testcase Class or they can be moved to the Testcase Superclass (page X) or a Test Helper (page X).

Example: Testcase Class

Here is an example of a simple Testcase Class:

public class TestScheduleFlight extends TestCase {
  
   public void testUnscheduled_shouldEndUpInScheduled() throws Exception {
      Flight flight = FlightTestHelper.getAnonymousFlightInUnscheduledState();
      flight.schedule();
      assertTrue( "isScheduled()", flight.isScheduled());
   }
  
   public void testScheduledState_shouldThrowInvalidRequestEx() throws Exception {
      Flight flight = FlightTestHelper.getAnonymousFlightInScheduledState();
      try {
         flight.schedule();
         fail("not allowed in scheduled state");
      } catch (InvalidRequestException e) {
         assertEquals("InvalidRequestException.getRequest()", "schedule",
                      e.getRequest());
         assertTrue(  "isScheduled()", flight.isScheduled());
      }
   }
  
   public void testAwaitingApproval_shouldThrowInvalidRequestEx() throws Exception {
      Flight flight = FlightTestHelper.getAnonymousFlightInAwaitingApprovalState();
      try {
         flight.schedule();
         fail("not allowed in schedule state");
      } catch (InvalidRequestException e) {
         assertEquals("InvalidRequestException.getRequest()", "schedule",
                      e.getRequest());
         assertTrue(  "isAwaitingApproval()", flight.isAwaitingApproval());
      }
   }
}
Example TestcaseClassPerFeature embedded from java/com/clrstream/ex3/solution/flightbooking/domain/flightstate/featuretests/TestScheduleFlight.java

Testcase Class

How It Works

Why We Do This

Implementation Notes

Example: Testcase Class

Further Reading