Previously I posted a little demonstration of capturing parameters passed into a mock with the newest version of Easy Mock. This was handy for those situations where you want to make assertions about how a class under test interacts with its collaborators. In this post I will show another cool new feature of Easy Mock: dynamic mock method returns values
This week myself and a few of my co-workers at Improving Enterprises had a chance to review the latest (0.8) release of the Buy a Feature online game. It was nice to see how development of the game had progressed and of course we had a lot of fun.
I wanted to sketch out a screen recently in a manner that didn’t imply any specific technology so I took a couple of hours to explore two ways of rapidly prototyping.
I have worked off an on the last couple of days to migrate the easyb and Infinitest plugins for IntelliJ to IntelliJ 8. Much to my delight the changes that the JetBrains folks made to the the plugin API were not backwards compatible with previous versions, were not clearly defined, and certainly were not well documented. After much experimentation, the sacrifice of a couple of goats, and a little help from the awesome (really) IntelliJ support fourms I now have both of these plugins working with the latest version of IntelliJ. Of course due to the changes in the plugin API they won’t run in older versions of IntelliJ and I don’t plan on adding new features to these versions in the future. The latest versions of both plugins have been uploaded to the IntelliJ plugin repository and can be downloaded from within IntelliJ. Please report any bugs you find or features you would like added to http://code.google.com/p/easyb/ and http://code.google.com/p/infinitest/ respectively.
I’ve recently starting falling back out of whatever tenuous blogging habits I had been working towards and would like to warm back up by sharing a cool little trick I discovered in the last week. In this blog I will show a new feature of EasyMock 2.4 which allows parameters passed to mocks to be captured and referenced elsewhere in the test.
This Friday, November 14, Improving Enterperises is partnering with Microsoft and the C# SIG to host a FREE one-day conference focusing on applying agile methods and development practices in the context of .NET development. I will be co-presenting a session on Test Driven Development and Behavior Driven Development along with Tony Mocella. This looks to be an exciting event and a great opportunity to explore the ideas behind agility with fellow members of the .NET community, or at least to see me struggle to code in C# on a PC. For more information and to register go to http://www.agiledotnet.com.
A week from Monday on October 27 Andy Glover and are running a half day tutorial at SD Best Practices on using easyb for Behavior Driven Development (BDD) and as a communication tool in story writing. If you’re going to be in Boston for this conference and are interested in learning more about how easy it can be to write stories and bind them to tests using easyb then please join us for this tutorial. Just bring your laptop along and we’ll provide everything else you need to get up to speed quickly with easyb.
I was writing a test for easyb in which I wanted to test the membership of a collection like this:
List<EasybSnippet> behaviors = parser.splitBehaviors(); assertThat(behaviors, is(asList(new EasybSnippet(3, 1), ...)));
To make this work I added the appropriate equals and hashCode methods to the EasybSnippet class allowing the collection comparison to work naturally. However, my code coverage check immediately popped since the new methods were in production classes and the incidental coverage that this test provided wasn’t sufficient to cover all paths. This caused me to pause, should I really have changed the natural equality of a production class to make a test work the way I wanted?
In the end I decide to replace this approach with a custom Hamcrest matcher and I was quite pleased with the result. The typically ugly equals and hashCode methods and their corresponding tests were replaced with a simple matcher.
public class EasybSnippetMatcher extends TypeSafeMatcher<EasybSnippet> {
private EasybSnippet snippet;
public EasybSnippetMatcher(EasybSnippet snippet) {
this.snippet = snippet;
}
public static Matcher<Iterable<EasybSnippet>> hasSnippets(EasybSnippet... snippets) {
return IsCollectionContaining.hasItems(/* convert snippets to matcher array *);
}
public boolean matchesSafely(EasybSnippet other) {
return snippet.start.line == other.start.line && ...
}
public void describeTo(Description description) {
description.appendText(snippet.toString());
}
}
And the resulting test case read even more naturally:
List<EasybSnippet> behaviors = parser.splitBehaviors(); assertThat(behaviors, hasSnippets(new EasybSnippet(3, 1), ...)));
In the past I have always been a little hesitant to create matchers too quickly because it always seemed like more work then letting the IDE generate the equals and hashCode methods for me. But I think I will more quickly grab the matcher tool from my tool-belt in the future when I find myself creating equals and hashCode methods in support of a test case.
Today I released InfiniJ 4.0.3 which provides better support for multi module projects. This new version allows you to mark modules which should be monitored by InfiniJ by adding a facet. This allows InfiniJ to associate an instance of Infinitest to each module you’re interested in monitoring. Each instance will run with the classpath specific to the module. This also provides the additional benefit of allowing InfiniJ settings (currently only whether a module is monitored or not) to be stored with the project’s metadata. Enabling InfiniJ is easy, simply add an Infinitest facet to each module you would like monitored. You can also view this quick screen cast to see a quick walkthrough of how this is done: Getting Started with InfiiniJ 4.0.3
I’ve been kind of quiet on my blog for a while, largely because of my newly acquired tennis addiction, but also because I have been working on an article about easyb. I recently wrapped this up and JavaWorld published it last Friday. So if you’re interested in reading about Behavior Driven Development with the easyb framework then you can read it at http://www.javaworld.com/javaworld/jw-09-2008/jw-09-easyb.html.