http://saffgreenbar.blogspot.com

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
  milliseconds
• 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
  otherwise.

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 {
   @Rule
   public TemporaryFolder folder= new TemporaryFolder();

   @Test
   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();
               else
                       return base;
       }

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

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

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

		@Test
		public void throwsNothing() {

		}

		@Test
		public void throwsNullPointerException() {
			thrown.expect(NullPointerException.class);
			throw new NullPointerException();
		}

		@Test
		public void throwsNullPointerExceptionWithMessage() {
			thrown.expect(NullPointerException.class);
			thrown.expectMessage("happened?");
			throw new NullPointerException("What happened?");
		}
	}

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

    @RunWith(Interceptors.class)
    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());
        }
    }

http://books.google.com/agreement

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));

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.

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) {
   c.compareTo(null);
}