JUnit

Up to this point in the book, we have been using single test suites to test just the methods that begin with the word "test." We also looked at how to run all test classes in a batch from a particular directory using Ant. Now let's take a look at how to create custom test suites and reuse fixture code.

Custom Test Suites

JUnit allows us to build our own test suites. Furthermore, suites can contain other suites, which makes for a powerful concept despite JUnit's simplicity. The following code excerpt from our AllTests.java file (in the timex/ directory) demonstrates how to build custom suites.

TestSuite modelTestSuite = new TestSuite("Model Tests"); modelTestSuite.addTestSuite(TimesheetManagerTest.class); TestSuite controllerTestSuite = new TestSuite("Controller Tests"); controllerTestSuite.addTestSuite(TimesheetListControllerTest.class); TestSuite fullSuite = new TestSuite("All Tests"); fullSuite.addTest(modelTestSuite); fullSuite.addTest(controllerTestSuite); return fullSuite;

Test Fixture Code

When we write unit test classes, it is a good idea to move test "fixture" code to a parent class, which in turn can extend the junit.framework. TestCase class.

A fixture is a set of objects (for example, test data) that might be used by one or more test cases. The benefit of a fixture is that it helps us avoid redundant setup and teardown code. For example, on past projects, I have moved the JDBC connection code, the Spring application context-loading code, and various other common code to a parent class. See junit.sourceforge.net/doc/cookbook/cookbook.htm for details on fixture code.

For our sample application, our fixture code has been moved up to the constructor of a parent class named TimexTestCase, as shown here:

protected TimexTestCase() {   FileSystemResource res =           new FileSystemResource("src/conf/timex2-servlet.xml");   springFactory = new XmlBeanFactory(res);   departmentManager = (DepartmentManager)           springFactory.getBean("departmentManagerProxy");   employeeManager = (EmployeeManager)           springFactory.getBean("employeeManagerProxy");   timesheetManager = (TimesheetManager)           springFactory.getBean("timesheetManagerProxy");   applicationSecurityManager = (ApplicationSecurityManager)           springFactory.getBean("applicationSecurityManager"); }

Note that I have set up the fixture code in a constructor. You could also set this up in the JUnit setUp method. Alternatively, if you are using JDK 1.5 or later, you can use annotations to initialize your fixtures (visit the junit.org website for details on this feature).

Now, classes such as TimesheetManagerTest can extend our new TimexTestCase class instead of directly inheriting TestCase, as shown in this example:

public class TimesheetManagerTest extends TimexTestCase

By having common fixture code in the TimexTestCase parent class, all subclasses can have instant access to precreated and fully set up objects (thanks to Spring's dependency injection). This enables the subclasses to focus on implementing the unit tests to pass user acceptance tests, versus spending time setting up fixtures for each test case.

For additional details on unit testing, test fixtures, test suites, and related topics, visit the junit.org website.