Help JUnitMax play with Hamcrest 1.3

I have been working on converting our codebase to JUnit, with a secondary aim of trying out JUnitMax.

I ran the Max and quickly discovered that it failed when trying to execute assertions using the Hamcrest hasItems matcher.

The assertion looks something like:

NoSuchMethodException describeMismatch

This error frequently occurs because JUnit packages an older Version of the org.hamcrest.Matcher class which does not have the describeMismatch method.

I dug around a bit in the plugins directory in the eclipse install folder and found that it contains a junit-4.8.2.jar. Happy days I thought, I can simply do what I’ve been getting used to doing for a while and replace it with junit-dep-4.8.2.jar which does not contain the hamcrest classes.

Unfortunately this didn’t quite work. It turns out that you need to call it exactly the same junit-4.8.2.jar. I thought this was because there’s an entry in the MANIFEST.MF file but I tried to change it and that didn’t work too well.

Renaming the Jar file however works a treat and now I have full JUnitMax action on my box.

I’ve posted on the JUnitMax forums about the problem here.


Make Fireworks IntelliJ Plugin Ignore Integration Tests

The Fireworks Plugin for IntelliJ allows you to automatically run all your unit tests when you make a change to the code.

Its a well behaved plugin, it allows you to configure wether or not to do this so you can just turn it on or off.

Whilst using it I made a detour to Shave a couple of Yaks. So thought I’d document it here.

I found it was also running some integration tests which relied on the file system and so didn’t work because there doesn’t appear to be a way to specify the working directory (you can specify JVM args so I could use that instead. I submitted an issue.

In the mean time, actually I thought I would rather not run my integration tests. Fortunately Fireworks allows a regex pattern to decide which files are tests.

After some hunting, I found the following post on stack overflow which gave me the clues i needed to include Test but not IntegrationTest.

The solution takes advantage of “lookaround” features of regex. The syntax in question is:


The (?! regex ) syntax means negative look ahead. You can put any regex in there. In our case, just “Integration”. This says, something not followed by “Integration”.

The code on stack overflow had some unnescessary syntax at the beginning (^) and I changed the ordering around a bit to make it read more logically.


The first “^” was unnescessary, and putting the “.” first made it read better i think. The parentheses are to provide some structure (regex groups) more than any functional reason.

So in words, the new expression reads “match any repeating character (.*) not followed by “Integration” (?!Integration)), then only match if “Test” is on the end.

Here is a test case for it (which along with some other regex stuff can be found on Github :

    public void matchesUnitTestsButNotIntegrationTests() {
        String expression = “(.(?!Integration))*Test”;
        Pattern pattern = Pattern.compile(expression);
        assertThat(pattern.matcher(“SomeUnitTest”).matches(), is(true));
        assertThat(pattern.matcher(“SomeIntegrationTest”).matches(), is(false));
        assertThat(pattern.matcher(“SomeNonTestClass”).matches(), is(false));

I found it hard to get this to work on the command line with grep. But I’ve got too much YAK HAIR on my floor now!

Now the Yaks are shaved I can go back to putting a system property in to allow my integration test to work.


Passing System Properties and Environment Variables to unit tests in Maven – Update

Unfortunately there was an bug in my previous post.

I had naively assumed that the syntax for environment variables was the same as for system properties but alas not.

The correct code is:

                       some value


Passing System Properties and Environment Variables to unit tests in Maven

This is a bit of dark magic …


I’m afraid I had to update this post as initially I naively assumed that the syntax for environment variables was the same as for system properties. As you can see from above, you have to actually put a separate xml tag in there for the variable.

By putting the value in ${} you can then pass it in with -DsomeSystemProperty from the command line when you do mvn clean install

e.g. :

mvn -DsomeSystemProperty=foobar clean install

YourKit: The best thing since sliced bread!

What is it?

A Java / .NET profiling tool.

YourKit, LLC is a technology leader, creator of the most innovative and intelligent tools for profiling Java & .NET applications. The YourKit Java Profiler has been already recognized by the IT professionals and analysts as the best profiling tool.

With YourKit solutions, both CPU and memory profiling have come to the highest professional level, where one can profile even huge applications with maximum productivity and zero overhead.

There are several, recent innovations to profiling that have gained well-deserved popularity among professional Java developers, both in big and small companies.

YourKit is the standard-setter in the evolution of profiling tools.

It is incredibly slick and easy to use. Thanks to Felix for putting me on to it.

Simply download it (Java, .NET), copy it to your Applications folder and add the following to your java startup options (on a mac, that is):

 -agentlib:yjpagent "	

Then kick back and enjoy!