Ketan's Musings

Monday morning excitement. JUnit tests that pass in the IDE fail in ant and cruise servers running on all platforms.

java.lang.AssertionError:
Expected: a string containing "... text=Ç..."
     got: "... text=Å..."

My immediate reaction was the encoding used by the JVM. Setting the “file.encoding” system property to UTF-8 did not help. Running the ant based tests in remote debugging mode also confirmed that the two strings were indeed different.

Since the tests used Cobertura for code coverage, the next step was to disable cobertura. Cobertura manipulates the generated byte code to add logging statements for code coverage. Still the same error.

The hidden gem seemed to be the -encoding java compiler flag. Setting it to UTF-8 fixed the problem.

So the next time you have something fail because of an encoding issue, it could just be the compiler encoding and not just the encoding used in the runtime!

If you use ant to run your builds, and would like to receive growl notifications about execution status, presenting Growl notifications for ant.

All you need to do is execute:

ant -listener com.google.code.ant.growlnotify.GrowlListener

And you’ll need is the growlnotify binary somewhere on your path, this is bundled with the Growl binary dmg.

So apple finally provided this update after a long time. You can download the update from http://www.apple.com/downloads/macosx/apple/application_updates/javaformacosx105update1.html.

Read more about the release notes at http://docs.info.apple.com/article.html?artnum=307403

Now that I’ve got your attention. Mockito is not just better than the other mock frameworks out there, it’s infact the best out there.

After reading a lot of noise from fellow ThoughtWorkers in the recent past about Mockito. I decided to give a yet another mock framework a try.

Here’s what I ended up writing:

public class RecorderLauncherTest extends TestCase {

	private RecorderListener listener;
	private RecorderLauncher launcher;
	private TestRunner runner;

	protected void setUp() throws Exception {
		super.setUp();
		listener = mock(RecorderListener.class);
		runner = mock(TestRunner.class);
		launcher = new RecorderLauncher(runner, listener);
	}

	public void testNotifiesListenerWhenLauncherStarts() throws Exception {
		launcher.launch();
		verify(listener).start();
	}

	public void testNotifiesListenerWhenExecutionFails() throws Exception {
		stubVoid(runner).toThrow(new RuntimeException()).on().run();
		launcher.launch();
		verify(listener).start();
		verify(listener).error();
	}

	public void testNotifiesListenerWhenExecutionCompletes() throws Exception {
		launcher.launch();
		verify(listener).start();
		verify(listener).finish();
	}

}

What’s even nicer is that it’s actual code and not strings, and refactoring tests do not break my mocks.

Good bye expect-run-verify, hello run-verify.

This looks, and reads far better than the JMock syntax, and it was love at first sight; I’m test-infested now. If you have not tried mockito as yet, I’d recommend that you do. I’m sure you’ll love it too.

Read more about using JRuby or Groovy to write eclipse plugins here: http://dev.eclipse.org/blogs/wayne/2007/07/26/making-eclipse-plug-ins-using-jruby-or-groovy/