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

	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?");
		}
	}

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:

    @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());
        }
    }

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

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:

http://books.google.com/agreement

If you are running your JUnit 4.5 tests with a direct call to JUnitCore.run, 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));

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.

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

We’ve released JUnit 4.5.  Potential extenders should find more support, and I find the design fits in my head much better than it once did.  Share and enjoy!

I’m coming up on my first anniversary developing software in MacLand.  By and large, I can’t explain what took me so long, and I happily upgraded soon after to OS X 10.5, Leopard.

What follows is one of those blog posts that is more likely to be useful to a random person hitting here from a Google search than regular (?!) readers of this blog.  You’ve been warned.

It’s been noted that Spaces is a great tool for organizing applications, but it has the odd idea that Spaces should be assigned by Application, rather than by window.  This is rather silly, since for each development project, I’m likely to have a browser window or two open, plus a terminal or Emacs instance, plus, often, an Eclipse workspace, and these have much more to do with each other than with other windows from the same applications.

It’s especially annoying, because I have one Emacs window that I’d like to follow me to all Spaces, while the others stay put.  I finally figured out how to make this happen: convince OS X that I have two totally different applications that happen to both run Emacs:

1. Copy Emacs.app from the Applications folder to some other location (say, the Desktop)
2. Rename Emacs.app to Glemacs.app (I can explain the name, if anyone comments and asks…)
3. In Finder, right click on Glemacs, and Show Package Contents.
4. Browse to Contents/MacOS, and rename Emacs to Glemacs
5. Go back and edit Contents/Info.plist.  Look for this text:

<key>CFBundleExecutable</key>
<string>Emacs</string>
<key>CFBundleIconFile</key>
<string>Emacs.icns</string>
<key>CFBundleIdentifier</key>
<string>org.gnu.Emacs</string>

and edit like so:

<key>CFBundleExecutable</key>
<string>Glemacs</string>
<key>CFBundleIconFile</key>
<string>Emacs.icns</string>
<key>CFBundleIdentifier</key>
<string>org.gnu.Glemacs</string>

6. Finally, copy Glemacs from your Desktop back into Applications (copying it back in triggers some necessary registration.

Now, OS X recognizes two different Applications, Emacs, and Glemacs, and you can change Spaces settings for them independently. Share and Enjoy.