.com
Hosted by:
Unit testing expertise at your fingertips!
Home | Discuss | Lists

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

Further Reading

In some variants of xUnit, most notably VbUnit and NUnit, the Testcase Class is called a test fixture. This use of the term should not be confused with the test fixture which consists of everything we need to have in place before we can start exercising the system under test (SUT)(These are the preconditions of the test.) Neither should it be confused with the fixture term as used by the Fit framework which is the Adapter[GOF] that interacts with the Fit table and thereby implements a Data-Driven Test (page X) Interpreter[GOF].



Page generated at Wed Feb 09 16:39:47 +1100 2011

Copyright © 2003-2008 Gerard Meszaros all rights reserved

All Categories
Introductory Narratives
Web Site Instructions
Code Refactorings
Database Patterns
DfT Patterns
External Patterns
Fixture Setup Patterns
Fixture Teardown Patterns
Front Matter
Glossary
Misc
References
Result Verification Patterns
Sidebars
Terminology
Test Double Patterns
Test Organization
Test Refactorings
Test Smells
Test Strategy
Tools
Value Patterns
XUnit Basics
xUnit Members
All "XUnit Basics"
Test Method
--Four-Phase Test
Assertion Method
--Assertion Message
Testcase Class
--Test Fixture
Test Runner
Testcase Object
Test Suite Object
--Test Discovery
--Test Enumeration
--Test Selection