Update: I cleaned up the example based on Rogerio’s comments.

Recently I stumbled onto JMockit and have been pretty impressed with the flexibility of the approach it takes.

Many mocking frameworks seem to take an elitist attitude toward testable code, not attempting to solve certain problems in favor of guiding one toward a more testable design. It appears JMockit is a response to this.

There’s no getting around the fact that some frameworks, especially legacy or proprietary third party modules, are not coded in such a way that it’s easy to write testable code against them. Common pain points include:

• Pervasive use of statics
• Lack of dependency injection mechanisms
• Creating dependencies inline with the “new” keyword

All of these issues will pose problems when trying to double-out dependent code for testing purposes. One approach to solve these problems is to use a dynamic language and metaprogramming constructs to do this kind of doubling. Testing Java code with JRuby or Groovy has become more and more popular for this very reason.

But a lot of these will introduce a level of language abstraction between your test code and the code under test, and you’ll have to have developers maintaining a test suite sign on to learn the language being used.

In comes JMockit, which uses the instrumentation features provided with Java5 to perform a lot of the same magic tricks for you.

This also allows you to test things that weren’t otherwise possible (or are very difficult) and overall I think the programming model is much more in-tune with standard Java programming idioms. It doesn’t discriminate against you if you don’t use dependency injection, but will work with you if you do. Here’s a quick example that colleagues Andy Pemberton and Patrick Cox worked through with me trying out JMockit.

You can get the whole project from my GitHub account.

More Related Content

• February 17, 2009 -- Don’t Unit Test Anymore… No, Really! (6)
• June 3, 2009 -- What is Hamcrest? (0)
• January 31, 2009 -- In response to Stackoverflow #38/”Quality Doesn’t Matter That Much” — Jeff and Joel (3)
• November 28, 2008 -- Must Haves/References For Modern Java EE Developers (1)
• July 8, 2010 -- Transactions, Part 1 (0)
• January 7, 2010 -- Eliminate Branching (IF Statements) to Produce Better Code (0)
• July 29, 2009 -- What I’d Tell Myself About Design If I Were Just Beginning (5)
• July 24, 2009 -- The Elements of Reusable Code (0)
• April 15, 2009 -- OSGi-ggity-Giggity (4)
• November 19, 2008 -- Java 6 and Maven 2.0.9 on Leopard (7)

As of JUnit 4.4, if you happen to peek into the distributed JAR you’ll notice something a little off: in addition to the org.junit.* packages there is this a funny-looking org.hamcrest.* package sticking out like a sore thumb. You may have seen other projects pick up a dependency on Hamcrest lately as well, and I bet you’re wondering what it is. Let’s get to the bottom of it.

Introduction

The “I’m Feeling Lucky” Google search for the term hamcrest currently takes you to the project’s Google Code page that states Hamcrest:

Provides a library of matcher objects (also known as constraints or predicates) allowing ‘match’ rules to be defined declaratively, to be used in other frameworks.

That’s a pretty good description if you already know what a Matcher is… but it doesn’t explain much for a beginner. So what does Hamcrest really do for you? 

It's just like... It's just like... A mini... REGEX!

A good way to think of it is that Hamcrest is to objects what regular expressions are to text.
Hamcrest provides you with a set of methods that effectively define a DSL to do pattern-matching on objects.

What can you use it for? Well, like regular expressions, the possibilities are endless. Some really novel uses have come about recently, but the most prominent use has been in the area of testing – hence the JUnit dependency.

A Brief History

Hamcrest evolved out of the library JMock, being used to write specialized constraints on what you expected to happen to a Mock object when standing in for a real implementation. A more fluent assertion syntax arose from these constraints which allowed you to chain together main constraint calls under a single assertThat method. Later JMock’s author, Joe Walnes, refactored the constraint API out into its own library called Hamcrest as people became interested in using it outside of a testing framework for all kinds of different things. He also started calling the constraints “matchers” though they can go by both names or, in some circles, “predicates.” Other testing frameworks and even JUnit, notorious for not requiring any dependencies and staying conceptually small, have picked it up.

All those old friendly org.junit.Assert.* static methods are still around in JUnit 4.4+. They’re useful for certain things, but by and large they’ve fallen out of style. The new kid on the block, JUnit’s assertThat method allows you to pass a Matcher in to create an assertion that you would otherwise use a specialized-assert method. Why is assertThat so useful? A few different reasons. Not only does it provide a more generic way to specify assertions, it also alows the framework to know specifically what you’re trying to assert. That allows the framework to generate failure messages for you.

Fail message… win?

It’s always been a good idea to use the overridden version of assertX method that also takes a String for a failure message, for example:

If we passed in an object representing a childhood version of Blackbeard, say, (before he took to the high-seas) then we’d expect to see our failure message:

It’s always been a good idea to provide these messages. But there’s no getting around the fact that they’re repetitive, tedious, and redundant.

Using Hamcrest matchers alongside assertThat makes JUnit smart enough to generate meaningful failure messages for you: writing your assertion with Hamcrest matchers provides the framework with enough contextual information to generate meaningful failure messages on your behalf. No need to maintain an extra arbitrary String to make sense of your failed assertions:

This may not look like much of an improvement, but it also doesn’t read any worse. We can ditch the extra String parameter as well. When this fails we’ll get a pretty cool failure message for free:

Note: I’m using JUnit 4.6 – in order to get this syntax to work you need to do some static imports:

It looks like there’s still work being done to make this DSL read more fluently in JUnit; something like:

Other Cool Stuff

Getting Reused

TestNG, JMock and many other testing frameworks will certainly benefit from what Hamcrest offers, but we’re starting to see this being used in many other places as well. I’ll be interested to see how well matchers work together or are maintained seeing that they’re relatively easy to create. Hopefully frameworks will contribute useful matchers back to the project.

Chaining

Because the matchers are implemented as a DSL using the method chaining idiom, they’re extremely easy to combine and extend.

Matchers For Regular Expressions

To bring the blog post full circle, I found this earlier tonight: the Hamcrest Text Patterns project. Its goal is to have you write Hamcrest-style regular expressions using matchers which will produce much more readable regular expression code. For example, have a look at this test that I found in the project:

By providing a friendly name for each capture (user, host, scheme, email) you can provide meaningful messages programmatically about what doesn’t match up when something doesn’t match.

Conclusion

I hope you choose to take a closer look at Hamcrest because it brings a big bang-for-the-buck and has the potential to guide us to more human-friendly, readable code.

Further Reading

• Have a look at Joe Walnes’ blog for a great introduction to using assertThat as well as other creative uses of Hamcrest matchers.
• Also take a look at Nat Pryce’s blog for more info on Hamcrest and Testing in general.

More Related Content

• June 9, 2009 -- Mocking with JMockit (5)
• April 15, 2009 -- OSGi-ggity-Giggity (4)
• November 19, 2008 -- Java 6 and Maven 2.0.9 on Leopard (7)
• July 8, 2010 -- Transactions, Part 1 (0)
• January 7, 2010 -- Eliminate Branching (IF Statements) to Produce Better Code (0)
• July 29, 2009 -- What I’d Tell Myself About Design If I Were Just Beginning (5)
• July 24, 2009 -- The Elements of Reusable Code (0)
• February 17, 2009 -- Don’t Unit Test Anymore… No, Really! (6)
• November 28, 2008 -- Must Haves/References For Modern Java EE Developers (1)
• September 10, 2008 -- Axis2 client using ADB – runtime dependencies (6)