Back to blogger

November 14th, 2009 by David Saff in Uncategorized

I’ve gotten a little too fed up with trying to post code in wordpress, and have been wanting to try eating Google’s own dogfood and use So, let’s continue the conversation there:

Rules in JUnit 4.7

July 16th, 2009 by David Saff in Uncategorized


JUnit 4.7 will include a new mechanism for changing the behavior and
interpretation of test methods.  We are calling this feature Rules
(replacing the earlier name Interceptors).  You can download a
snapshot of this release.  We are planning no new
feature for this version, and once the tagged bugs are resolved, we will issue an
official release candidate, but early feedback is very, very welcome.

There are already rules you’re probably familiar with from way back in
JUnit 4.0:

  • The fundamental rule of JUnit: a test method is executed on a new
    instance of its declaring class.  It passes if and only if it
    completes without throwing an exception.
  • The Before rule: a @Test method is preceded by all @Before methods
    in the same class.
  • The After rule: a @Test method is followed by all @After methods in
    the same class.
  • The timeout= rule: if a @Test annotation has a timeout= property, it
    fails if it does not complete in under the given number of
  • The expected= rule: if a @Test annotation has an expected= property,
    it passes if it throws an exception of the given class name, and fails

Starting with 4.7, you can add additional rules to methods in a class
by declaring public fields in the class annotated with @Rule.  For
example, here’s a test that uses the TemporaryFolder rule (“All files
created in the temporary folder during the test are deleted after the
test completes.”):

 public static class HasTempFolder {
   public TemporaryFolder folder= new TemporaryFolder();

   public void testUsingTempFolder() throws IOException {
     File createdFile= folder.newFile("myfile.txt");
     File createdFolder= folder.newFolder("subfolder");
     // ...

We’re including implementations of the following Rules:

  • TemporaryFolder: delete temp files after test completion
  • ExternalResource: reliably set up and tear down an arbitrary external resource
  • ErrorCollector: collect multiple assertion failures per test method, and report all at the end
  • Verifier: turn a passing test to failing if an arbitrary condition is not met (all expected mock-object calls made, no ERROR lines in the logs)
  • TestWatchman: Perform an additional task before and after each test (a custom log, for example)
  • TestName: remember the name of each test method, and make it available during the test execution.
  • Timeout: like the timeout= rule, but applies to all methods in a class, and can take a run-time value.
  • ExpectedException: like the expected= rule, but can check exception messages, and other arbitrary assertions.

For more on using these rules, please see the release notes.

In addition, you can implement your own Rules by implementing the
MethodRule interface.  Here’s a Rule that marks all tests as passing,
as long as I’m the one running them:

public class DavidsAlwaysRight implements MethodRule {
       public Statement apply(Statement base, FrameworkMethod method, Object target) {
               if ("saff".equals(System.getenv("USER")))
                       return alwaysSuccess();
                       return base;

       private Statement alwaysSuccess() {
               return new Statement() {
                       public void evaluate() throws Throwable {
                               // do nothing: always success!

While you’re here, don’t forget the T-shirt.

JUnit 4.7: Interceptors: expected exceptions

May 26th, 2009 by David Saff in Uncategorized

In the latest snapshot build of JUnit 4.7, we’ve re-implemented expected exceptions using Interceptors. Share and Enjoy!

	public static class HasExpectedException {
		public ExpectedException thrown= new ExpectedException();

		public void throwsNothing() {


		public void throwsNullPointerException() {
			throw new NullPointerException();

		public void throwsNullPointerExceptionWithMessage() {
			throw new NullPointerException("What happened?");

Getting the name of the currently-running test method

May 11th, 2009 by David Saff in Uncategorized

One of the most common requests since JUnit 4.0 was released has been to restore a somewhat accidental feature of JUnit 3.8.  Since, in 3.8, the same object handled test execution and test lifetime management, a test method had access to the getName() method of TestCase, which was internally used for reporting.  Many extenders used this fact to build informed lightweight logging functions.  In JUnit 4.0, this accidental feature was not replicated, which made it difficult to port some of these logging routines.

In the latest snapshot of JUnit 4.7, we’ve re-introduced this feature, by way of Interceptors.  It looks like this:

    public class NameInterceptorTest {
        @Interceptor public TestName name = new TestName();

        @Test public void testA() {
            assertEquals("testA", name.getMethodName());

        @Test public void testB() {
            assertEquals("testB", name.getMethodName());

Interceptors in JUnit 4.7

May 5th, 2009 by David Saff in Uncategorized

For both of you that read this blog, and haven’t already seen it, there’s some fun stuff brewing in JUnit 4.7.

JUnit self-test wordle

December 3rd, 2008 by David Saff in Uncategorized

Google Book Search settlement

October 28th, 2008 by David Saff in Uncategorized

I had the privilege of spending a bit of time building a couple small testing tools to help some hard-working engineers and negotiators build a very interesting future:

Overriding the default Runner.

October 27th, 2008 by David Saff in Uncategorized

If you are running your JUnit 4.5 tests with a direct call to, you can override the default runner (BlockJUnit4ClassRunner) used to run tests that don’t otherwise have a @RunWith annotation:

RunnerBuilder builder = new AllDefaultPossibilitiesBuilder() { 
  @Override protected JUnit4Builder junit4Builder() {
    return new JUnit4Builder() {
      @Override public Runner runnerForClass(Class testClass) throws Throwable {
        return new MyCustomJUnit4ClassRunner(testClass);

new JUnitCore().run(new Suite(AllMyTests.class, builder));

Spaces flipping with X11 in OS X

September 10th, 2008 by David Saff in Uncategorized

Say you are using your MacBook to run Eclipse and some xterms from a Linux box through X11, and you distribute your X11 windows to different spaces.  (You’re probably using NX, so that you aren’t motivated by latency to throw a cat out the window after every mouse click…)  Every few moments, your monitor suddenly and violently flips to what feels like a random space.

I’m lucky enough to sit near Matthew Gray, who brainstormed this solution:

The combination of X11 + Spaces treats the UI Layer on which tooltips appear as a separate application: if you move Eclipse, but not the tooltips layer, Spaces will flip to the old space every time it even thinks about displaying a tooltip (sometimes, it appears, even without any actual tooltip being shown).  This is easy to miss, since the tooltip will go away as soon as you move the mouse.

The fix is one of those things that should never work, but does.  It also requires some skill.  Move the mouse to a place in the Eclipse window that should pop up a tooltip.  Keep the mouse very still while your Mac flips to the new space.  Now, without moving the mouse, press F8 to Show Spaces (if you still have the default keys enabled).  Now, carefully pick up the tool tip (which should still be showing, but very small), and drag it into the same space as Eclipse.

Of course, it would be great if X11 + OS X could work out a better way to play together, but this works for now.

Checking Exceptions with Theories

September 9th, 2008 by David Saff in Uncategorized

Robert Rees was astute enough to point out that it can be difficult to combine the expected-exception feature of JUnit 4 with Theories.  What if we want to say that any Comparable in our system should throw a null pointer exception if compared with null?  (By the way, it appears this is neither required nor disallowed by the Comparable contract.)

The current answer is a bit ugly: you need to combine the @Test and @Theory annotations:

@Theory @Test(expected=NullPointerException.class)
public void compareToNullThrowsNpe(Comparable c) {