JUnit tip: Setting the default timezone with a TestDecorator

A problem I was finding when testing XStream is that many of the tests were timezone dependent. Initially I had some code in each setUp()/tearDown() method to set the default timezone and reset it afterwards.

This lead to a lot of duplication. Putting the common code in a super class was an option but this lead to a fragile base class.

Using composition allows this commonality to be put in one case and applied to the relevant test cases. This gets out of the 'single inheritance' issue.

JUnit provides an (often overlooked) decorator class to help with this. Here's my TimeZoneTestSuite:

  public class TimeZoneTestSuite extends TestDecorator {

    private final TimeZone timeZone;
    private final TimeZone originalTimeZone;

    public TimeZoneTestSuite(String timeZone, Test test) {
      super(test);
      this.timeZone = TimeZone.getTimeZone(timeZone);
      this.originalTimeZone = TimeZone.getDefault();
    }

    public void run(TestResult testResult) {
      try {
        TimeZone.setDefault(timeZone); 
        super.run(testResult);
      } finally {
        TimeZone.setDefault(originalTimeZone); // cleanup
      }
    }

  }

To use it, you need to override the default test suite behavior by adding a method to your TestCase:

  public class MyTest extends TestCase {
    public static Test suite() {
      Test result = new TestSuite(MyTest.class); // default behavior
      result = new TimeZoneTestSuite("EST", result); // ensure it runs in EST timezone
      return result;
    }

TestDecorators are a very powerful feature of JUnit - don't forget about them.

Comments

Jon Tirsen

I really don't like TestDecorators. I know that design-wise they make better sense than a test-base-class that overrides setUp but usability is really a PITA. When I work in IntelliJ I want to just right-click a test-method, hit Run test... and have it running. With a TestDecorator I have to run the whole suite or manually create a suite with the test-method I want.

*blergh*

Alternatively, you could make your objects get time information through some abstract Clock interface. In unit tests you can provide your objects with a stub clock that has a hardwired timezone, date, time, etc. In production code you can provide them with a real clock that calls through the system's time APIs.

Name:
Email:
URL: