Open Source ProjectsCode that Might be Useful to You

Talks I've GivenOn Technologies and Ideas

ThoughtsWhere I Sometimes Write Things

Resume If You Still Believe In Those

Follow Me On

GitHubIf coding is your thing

TwitterIf you tweet

TumblrIf you're ADD

Of Dreams unfulfilled, JMock, and Expectations

I just had an observation about the pattern of setting up expectations of our jmock tests. So here’s a typical code block for setting it up:

final List<UserGroup> groups = this.groups;
final List<User> users = this.users;
final User user = users.get(0);

final UserService userService = this.userService;
this.jmockCtx.checking(new Expectations()
  // first, rehydrate
  // now, save

I was thinking, hey, why not just use this.groups, this.users, etc, directly in the expectations, instead of making new references to them? It might look like:

this.jmockCtx.checking(new Expectations()
  // first, rehydrate

This ends up being an error because ‘userService’ cannot be resolved or is not a field. Unexpected behavior, right? Almost.

A little background about what this code chunk is actually doing: when we do new Expectations() {}, we’re actually creating an anonymous subclass. At that point, ‘this’ would refer to the Expecations subclass, not the test we’re in.

When we do the second set of {}s, we’re adding an initializer block. The best way of thinking about this is that basically, it gets invoked when you instantiate an instance of an object, similar, but different to the normal contstructor. You may be more familiar with static initializer blocks, doing something like:

public class Something {
  private static Map map = new HashMap();
  static {

So my dream of using this.users and pals in my Expecations, can only be that, a dream.

comments powered by Disqus