nosewheelie

I’m happy to announce the release of Instinct 0.1.7. This is mainly a maintenance release, and includes the removal of in progress specification state, runners now emit pending reason, added Functional Java based matchers, upgrades to dependencies, Ant 1.7.1, CGLib 2.2, jMock 2.5.0 and Objenesis 1.1 and an internal re-write of specification runners.

Note that the upgrade to jMock 2.5.0 may cause issues with current mocks, you should consult the jMock documentation and release notes if you run into trouble. I’ve also added a new dependency on Functional Java, which is used both internally and can be used from two new matchers.

Downloads are available from the project site.

Here’s the full list of changes:

• Core Features
  • Removed in progress specification state, use pending instead.
  • All runners now emit pending specification reason.
• Expectation API
  • Added function matcher, e.g. expect.that(list).doesNotContain({int i => i > 3} (based on Functional Java’s fj.F).
  • Added fj.data.List matcher.
• Infrastructure
  • Added dependency on Functional Java, used both internally and for use in expectation API.
  • Continued clean up of specification running code.
  • Upgraded to: Ant 1.7.1, CGLib 2.2, jMock 2.5.0 and Objenesis 1.1.
• Bugs
  • (Issue 11) It would be nice not to have to depend on jmock when writing a BDD-style test involving no mocks.

Continuing my nobody *ever* uses series, here’s a Java example.

Consider the following horrible piece of Java code taken from Instinct which finds specifications to run:

private Collection<LifecycleMethod> findMethods(final MarkingScheme markingScheme) {
    final Collection<LifecycleMethod> lifecycleMethodSet = new HashSet<LifecycleMethod>();
    final Collection<Method> methods = methodLocator.locateAll(contextType, markingScheme);
    for (final Method method : methods) {
        lifecycleMethodSet.add(new LifecycleMethodImpl(method, contextType));
    }
    return lifecycleMethodSet;
}

Here’s the same method rewritten using Functional Java, with the conversion function pulled out for clarity:

private Collection<LifecycleMethod> findMethods(final MarkingScheme markingScheme) {
    final F<Method, LifecycleMethod> conversion = new F<Method, LifecycleMethod>() {
        public LifecycleMethod f(final Method a) {
            return new LifecycleMethodImpl(a, contextType);
        }
    };
    final Collection<Method> methods = methodLocator.locateAll(contextType, markingScheme);
    return toFjList(methods).map(conversion).toCollection();
}

The good thing about the above is it expresses succinctly what we’re doing; find the methods we’re interested in and map across them to convert them into another type. The unfortunate things are that we have to convert from a Java collection to a FJ collection (toFjList) and we need to use the clunky Java anonymous inner class as a pseudo first class function.

For comparison, here’s a rough stab (i.e. probably won’t compile) at what it’d look like in Scala, notice that implicits will take care of the conversion for us:

def findMethods(markingScheme: MarkingScheme) =
  methodLocator.locateAll(contextType, markingScheme).map(new LifecycleMethodImpl(_, contextType))

Now isn’t that better?