I’ve been misunderstanding a fundamental issue of Spock Mocks. That’s annoying, but probably inevitable given that I work with so many state-of-the-art, evolving API’s. If you spend enough time on the bleeding edge, sooner or later you’ll get cut.

The problem is, though, I’ve been telling people something wrong for some time now, and that’s not acceptable. Thus this blog post. It’s one thing for me to make a mistake, but it’s quite another for me to mislead others. I want to fix that now. Besides, if I made the mistake, it’s also possible others are missing it, too.

I’m a big fan of the Spock testing framework. It’s very easy to learn, it works with both Java and Groovy systems, and it’s got a great mocking framework built into it. I’ve been a JUnit user for years, but I’ve never been able to commit to a mocking framework in Java. That’s partly because I still don’t find them particularly intuitive, and partly because I’m still not sure which one is going to win. I don’t want to commit to a framework (EasyMock? Mockito? PowerMock? etc) only to have to switch to a different one in a couple of years.

Spock is fun, though, and I use it whenever I can, and not just for the Star Trek related puns, some of which I’ll have to adopt here. Back in June, I wrote an article for NFJS the Magazine, entitled “Spock: I have been, and always shall be, your friendly testing framework.” I’m going to use an example from that article, with some variations, to show what I recently learned.

A basic Spock test

Here is part of a Groovy class called Tribble that answers the question, “Do you know what you get when you feed a tribble too much?”:

class Tribble {
    def feed() {
        def tribbles = [this]
        10.times { tribbles << new Tribble() }
        return tribbles
    }
}

The answer, of course, is a whole bunch of hungry little tribbles. The feed method creates an ArrayList of tribbles by starting with the current instance and then adding 10 more. I know the return keyword isn’t strictly necessary, since closures automatically return their last evaluated value, but I use it sometimes for clear documentation. Groovy isn’t about writing the shortest code — it’s about writing the simplest, easiest to understand code that gets the job done.

To test this method, here’s a Spock test. It extends the spock.lang.Specification class (which is required) and ends in the word “Spec” (which isn’t, but makes for a nice convention):

import spock.lang.Specification

class TribbleSpec extends Specification {
    Tribble tribble = new Tribble()

    def "feed a tribble, get more tribbles"() {
        when:
        def result = tribble.feed()

        then:
        result.size() == 11
        result.each {
            it instanceof Tribble
        }
    }
}

I never thought JUnit was verbose until I met Spock. For those who haven’t used it much, first let me say you have something fun to look forward to. That said, let me explain the test. Spock tests have a def return type, then have a test name that describes what you’re trying to accomplish. The name is usually a short phrase, but it can be spread over several lines and even contain punctuation.

(Hamlet D’Arcy gives a great example in his blog post on Spock mocks, which is also echoed in the cool Spock Web Console. I also agree with him that Spock mocks should be called “smocks”, but since it doesn’t have a direct Star Trek association I’m not sure that will catch on.)

As Peter Niederweiser, the creator of the framework, points out, the method name becomes the body of an annotation, but that’s all under the hood.

The rest of the test consists of a when and a then block, representing a stimulus/response pair. The when block contains the method invocation, and the then block includes a series of boolean conditions that must be true for the test to pass. Nice and simple.

Tribbles do more than just eat, though. They react to others.

Like Dr. McCoy, I can mock Vulcans

Let me add a pair of methods to my Tribble class:

    String react(Klingon klingon) {
        klingon.annoy()
        "wheep! wheep!"
    }

    String react(Vulcan vulcan) {
        vulcan.soothe()
        "purr, purr"
    }

The overloaded react method is based on a pair of interfaces. Here’s the Vulcan interface:

interface Vulcan {
    def soothe()
    def decideIfLogical()
}

Here’s the Klingon interface:

interface Klingon {
    def annoy()
    def fight()
    def howlAtDeath()
}

(Yeah, I know howling at death is a Next Generation thing, but go with it.)

Since both Vulcan and Klingon are interfaces, a mocking framework can generate an implementation with just Java’s basic dynamic proxy capabilities, which means I don’t need CGLIB in my classpath. To test the react method that takes a Vulcan, here’s the Spock mocking feature in action:

    def "reacts well to Vulcans"() {
        Vulcan spock = Mock()

        when:
        String reaction = tribble.react(spock)

        then:
        reaction == "purr, purr"
        1*spock.soothe()
    }

Spock provides the Mock method to create a mock implementation of the interface. When I then invoke the react method, I check that it returns the proper String and (here’s the cool part), I verify that the soothe method in the mock is invoked exactly once.

So far, so good. Klingons react rather badly to tribbles, however, so I thought it would funny if I had them throw an exception. Here’s my original test for the react method that takes a Klingon (warning: this doesn’t do what it looks like it does!):

    def "reacts badly to Klingons"() {
        Klingon koloth = Mock()
        koloth.annoy() >> { throw new Exception() }

        when:
        String reaction = tribble.react(koloth)

        then:
        0*koloth.howlAtDeath()
        1*koloth.annoy()
        reaction == "wheep! wheep!"
        notThrown(Exception)
    }

Using the right-shift operator, my intention was to set the expectation that invoking the annoy method on a Klingon resulted in an exception. The plan was:

• In the setup block (above when), declare that the annoy method throws an exception,
• In the then block, verify that the method got called.

The problem is, what happens to the exception? Spock has two great methods for exception handling, called thrown and notThrown. I was able to verify that the method got called, but why did notThrown(Exception) return true? I even got back the string I expected. What’s wrong?

The right way to mock a Klingon

(from a galaxy far, far away, right?)

Here’s the problem: according to the Spock wiki page on Interactions, interactions defined outside a then block (here declaring that react throws an exception) are called global, while those defined inside a then block are called local, and local overrides global. Also, interactions without a cardinality are optional, while those with a cardinality are required.

In other words, I may have declared that react throws an exception, but in the then block I then changed it to say it actually doesn’t. In the then block, I say that react must be called once and doesn’t return anything. Therefore, no exception is thrown and the return value is as expected.

To achieve what I was actually after, here’s the right way to mock my Klingon:

    def "reacts badly to Klingons"() {
        Klingon koloth = Mock()
        1 * koloth.annoy() >> { throw new Exception() }
        0 * koloth.howlAtDeath()

        when:
        String reaction = tribble.react(koloth)

        then:
        reaction == null
        thrown(Exception)
    }

Now I set both the cardinality and the behavior outside the then block. The then block verifies both that the exception was thrown, and it checks the cardinality, too. Oh, and while I was at it, I verified that the howlAtDeath method didn’t get called. I doubt the Klingons howled at death when they burned down all the tribbles that Scotty beamed into their engine room just before they went to warp.

Admittedly, I still find the syntax a bit confusing, but at least I get it now. Hopefully you’ll get it, too, and they’ll be nah tribble at all.

(The source code for this example and the others used in my NFJS the Magazine article are in my GitHub repository, https://github.com/kousen/Spock-NFJS-Article . Eventually they will make their way into my book, Making Java Groovy, available now through the Manning Early Access Program.)

I’ve been teaching a lot of Spring framework classes lately. In one of them, we have a unit on Aspect Oriented Program (AOP) in Spring. Spring provides all the necessary infrastructure to make AOP doable. You can define aspects using annotations, and Spring will auto-generate the necessary proxies to implement them.

As an example, the materials (written for Java, of course), presented an aspect similar to this:

package mjg.aspects;

import java.util.logging.Logger;

import org.aspectj.lang.JoinPoint;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;

@Aspect
public class PropertyChangeTracker {
    private Logger log = Logger.getLogger(PropertyChangeTracker.class.getName());

    @Before("execution(void set*(*))")
    public void trackChange(JoinPoint jp) {
        String method = jp.getSignature().getName();
        Object newValue = jp.getArgs()[0];
        log.info(method + " about to change to " +
            newValue + " on " + jp.getTarget());
    }
}

For those who haven’t done AOP, or who haven’t done AOP in a while, an aspect consists of a pointcut and advice. The advice is what you want to do, and the pointcut is where you want to do it.

In this case, the pointcut is inside the @Before annotation. It states that the pointcut is before every method in the system that begins with set, takes a single argument (two dots would represent zero or more arguments — a single star is one argument) and returns void.

The advice is the trackChange method. Spring calls this method whenever the pointcut applies, and it supplies the JoinPoint argument from AspectJ. The join point provides context, because from it you can get the name of the method being called, its arguments, and a reference to the target object, as shown above.

This aspect logs properties that are about to change. Along with the Spring configuration file (which I’ll get to shortly), it demonstrates an aspect being applied in a very general way.

One of my students, however, had an obvious question. It’s all well and good to print out which set method is being called and on which object, but what would be really useful is to know what the value of the property was before the set method changed it. What’s the current value of the property?

The JoinPoint class doesn’t really have methods to determine that, unfortunately. The javadocs for AspectJ are located at Eclipse, of all places, if you want to take a look.

A friend of mine and I debated how we would go about figuring out the current value. Since we know the name of the setter method being invoked and we have a reference to the current object, some form of reflection and string manipulation would probably do the trick.

That’s when it hit me, though, that the job would be almost trivial in Groovy. Let me show you the answer and then talk about it. Here’s my Groovy aspect.

package mjg.aspects

import java.util.logging.Logger

import org.aspectj.lang.JoinPoint
import org.aspectj.lang.annotation.Aspect
import org.aspectj.lang.annotation.Before

@Aspect
class UpdateReporter {
    Logger log = Logger.getLogger(UpdateReporter.class.name)

    @Before("execution(void set*(*))")
    void reportOnSet(JoinPoint jp) {
        String method = jp.signature.name
        String property = (method - 'set').toLowerCase()
        def current = jp.target."$property"
        log.info "About to change $property from $current to ${jp.args[0]}"
    }
}

I called the aspect UpdateReporter. It defines the same pointcut as the PropertyChangeTracker. This time, though, it’s easy to figure out the current value of the property. I just subtract set from the name of the method and convert to lowercase, which gives me the property name. Then I invoke the get method by using the standard POGO convention that accessing the property invokes the getter. The string interpolation is just to make sure I evaluate the method rather than treat it as a string property of the class.

I now need a class with some set methods in it, so I made a POJO.

package mjg;

public class POJO {
    private String one;
    private int two;
    private double three;

    public String getOne() { return one; }
    public void setOne(String one) { this.one = one; }
    public int getTwo() { return two; }
    public void setTwo(int two) { this.two = two; }
    public double getThree() { return three; }
    public void setThree(double three) { this.three = three; }

    @Override
    public String toString() {
        return "POJO [one=" + one + ", two=" + two + ", three=" + three + "]";
    }
}

Here is the Spring bean configuration file, in XML.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:p="http://www.springframework.org/schema/p"
    xmlns:aop="http://www.springframework.org/schema/aop"
    xsi:schemaLocation="

http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans.xsd

http://www.springframework.org/schema/aop

http://www.springframework.org/schema/aop/spring-aop.xsd">

    <aop:aspectj-autoproxy />

    <bean id="updater" class="mjg.aspects.UpdateReporter" />
    <bean id="tracker" class="mjg.aspects.PropertyChangeTracker" />
    <bean id="pojo" class="mjg.POJO" p:one="1" p:two="2" p:three="3"/>
</beans>

The aop namespace contains the aspectj-autoproxy element, which tells Spring to pay attention to the @Aspect annotations and generate proxies as needed. Spring AOP applies at public method boundaries of Spring-managed beans, so I needed to add the POJO bean to the configuration file as well.

The final piece of the puzzle is to actually call the setter methods on the POJO, which I did with a test case. I used Spring’s JUnit 4 test runner to cache the application context.

(In other cases I use Spock’s Spring capabilities to do the same thing with Spock tests, but that’s another story.)

package mjg;

import static org.junit.Assert.*;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;

@ContextConfiguration("/applicationContext.xml")
@RunWith(SpringJUnit4ClassRunner.class)
public class POJOTest {
    @Autowired
    private POJO pojo;

    @Test
    public void callSetters() {
        pojo.setOne("one");
        pojo.setTwo(22);
        pojo.setThree(333.0);
        assertEquals("one", pojo.getOne());
        assertEquals(22, pojo.getTwo());
        assertEquals(333.0, pojo.getThree(),0.0001);
    }
}

The Spring test runner also injects the POJO into the test, which is convenient. Running the test then prints to the console (cleaned up a bit):

INFO: About to change one from 1 to one
INFO: setOne about to change to one on POJO [one=1, two=2, three=3.0]
INFO: About to change two from 2 to 22
INFO: setTwo about to change to 22 on POJO [one=one, two=2, three=3.0]
INFO: About to change three from 3.0 to 333.0
INFO: setThree about to change to 333.0 on POJO [one=one, two=22, three=3.0]

How cool is that? I love it when I find an application where Groovy makes life much easier than the Java alternatives. I have to admit that I was almost insufferably pleased with myself when I got this to work, though of course it’s all Groovy — and Spring’s very friendly relationship to it — that made it all possible.

By the way, what is that mjg package I keep using? Why, Making Java Groovy, of course. This example is going directly into the chapter on Groovy and Spring, so consider this a bit of a teaser.

I just added a new chapter discussing Groovy and SOAP-based web services to the Manning Early Access Program (MEAP) version of Making Java Groovy. I prepared a decent introduction for the MEAP subscribers, which I thought I would share here:

“Though they’ve fallen out of favor recently, SOAP-based web services provide a perfect opportunity for Java/Groovy integration. The technology is mature, with known use cases and a tool set that has been added to Java’s standard edition. In this chapter, I go over the basics of web services with a focus on the wsimport and wsgen tools that are built into JDK 1.6.

Using Groovy to build a client-side web service application is almost trivial. The wsimport tool generates Java stubs, which Groovy can instantiate and use like any other Java class. I illustrate a case where a publicly-available web service returns XML, rather than objects, which is much easier to process with Groovy than with Java.

To create a web service, I find it much easier to use Groovy if the service implementation bean supports a service endpoint interface, even though that is not strictly required by the specification. The standard interface/implementation split makes mixing Java and Groovy wherever desired quite easy, however. There is a slight complication when dealing with domain classes, but as long as they are annotated to prefer field access rather than properties, everything works just fine.

In general, with SOAP-based web services no XML is exposed on either the client side or the server side. The exception is when using handlers to pre- or post-process the messages. As usual, using Groovy for XML processing is much easier than Java. My proposed solution is to use a Java class to implement the appropriate Handler interface, but to delegate to a Groovy class for the actual XML processing and manipulation.

Finally, I present Gradle tasks to perform the wsimport and wsgen tasks, based on the corresponding Ant tasks.

Though much of the industry is switching from SOAP to REST, SOAP-based web services are going to be a fact of life at many companies for the foreseeable future. This chapter shows how you can use Groovy to make developing them and working with them easier.

Note that this is listed as Chapter 7 in the outline. The code examples do use some technologies covered in the intervening chapters (Spock tests, Gradle builds, and so on), but you don’t need the details to be able to read this chapter.”

These days whenever I discuss web services, I feel obligated to show the Gartner Hype Cycle. In case you haven’t seen it, here’s an image from Wikipedia:

I like the model, though I always suspect that the actual data Gartner periodically adds to the figure is pure hand waving speculation. In my experience, right now REST is rapidly approaching that Peak of Inflated Expectations. I know several people who have been successful with it, but the tools and APIs are still quite immature. I’m working on my REST chapter in Making Java Groovy at the moment, and while I can get everything to work, it’s taking more effort than I expected. Don’t get me wrong — I see the value in REST, but right now getting it to work with Java is a lot more effort than using SOAP, believe it or not.

(Obligatory moderately humorous anecdote: back when I was working at a training company about six or seven years ago, we were partners with the company that produced Crystal Reports for business intelligence reporting. They were eventually bought by a company called Business Objects (who in turn was bought by SAP, but that’s a different story). Anyway, Business Objects preferred the abbreviation BOBJ over that of B.O., for obvious reasons. Of course, we used to joke about teaching a BO class followed by a SOAP class….)

The attitude toward REST may be an overreaction, but that’s nothing compared to the loathing for SOAP-based web services you find in much of the community these days. You would think that SOAP would be safely on the Plateau of Productivity by now, but if you go to any conferences (or talk to any REST advocates) the contempt you see for SOAP is such that it must be deep in the Trough of Disillusionment.

I don’t necessarily agree, but fortunately I don’t have to resolve that argument. As I see it, one of the major tasks Java developers face these days is working with SOAP-based web services, probably as part of a (potentially misguided, but what can you do?) Service Oriented Architecture, and those services aren’t going away any time soon. Those same developers are also going to be working with REST, if not already then soon, and are starting to get used to terms like safe, idempotent, and HATEOAS.

My task is to show Java developers how Groovy can help in both situations. Chapter 7 discusses JAX-WS (the SOAP tool set for Java) and how it works with Groovy. Chapter 8 talks about REST and JAX-RS, with the same goal in mind. Hopefully I’ll be able to provide enough information that you’ll be able to make up your own mind as to whether Groovy is helpful in either case.

—-

On an unrelated note, next weekend (3/5 and 3/6) I’ll be at the No Fluff Just Stuff event in Minneapolis. I’m giving three presentations: one on improving your Java with Groovy, one on testing with Spock, and one on using Gradle for builds. Oh, and leave it to the Gradle people to announce another milestone release four days before I’m supposed to give a presentation on it. Sigh. That’s life in the Groovy ecosystem for you. In any case, I’m really looking forward to the event. If you plan to attend, please drop by and say hi, even if you’re just on your way to go see Neal Ford, Tim Berglund, the inimitable Dave Klein, or any of the other great speakers at the conference. I might even have a discount code to give out…

I often start Groovy development with scripts rather than classes. Scripts are quick and easy, both to write and to run, and the feeling of having only a few lines of code makes me more willing to experiment. Most of my scripts eventually turn into classes, but once in a while, either for convenience or as demos, they stay the way they are.

This happens a lot while I’m working on my book*. I often generate little scripts that illustrate one point or another, and most of them aren’t worth converting into classes.

(*What book is that, you say? Why, Making Java Groovy, which shows you how to add Groovy to Java to make your development tasks easier. It’s available now from the Manning Early Access Program at http://manning.com/kousen)

While I’m not sure I practice true Test Driven Development (TDD), I know I practice GDD. That’s Guilt Driven Development, which means if I write anything significant that isn’t tested I feel guilty about it, so I then write the tests. In this post I’ll show how I now write tests for my Groovy scripts.

Before I do so, however, I should acknowledge the assistance of the indefatigable Hamlet D’Arcy on the Groovy Users email list. He blogged about a similar issue back in 2006 (!). Of course, he was dealing with straight Java back then and trying to manage standard error.

There are two features I need to use:

• The groovy.lang.GroovyShell and groovy.lang.Binding classes, and
• Overriding System.out to capture printed output

I use a GroovyShell to execute the scripts, and a Binding to manage input and output variables, if any. To handle printed output, I redirect standard output to a ByteArrayOutputStream and then check the results.

To illustrate, here are three extremely powerful scripts. The first is the classic “Hello, World!” script in Groovy. I stored it in a file called hello_world.groovy.

println 'Hello, World!'

Second, here is a script that contains an assert in it, in a file I called script_with_assert.groovy.

def ok = true
assert ok

I used a local variable, called ok, in that script, mostly to contrast it with a binding variable. Speaking of which, here’s my super duper script that has a binding variable in it, stored in a file called script_with_variable.groovy.

package mjg.scripts
ok

Recall from the fantastic book Groovy in Action* (even after all these years and language changes, I still find valuable information in there) that if a variable in a script is not declared, then it can be set and retrieved via an instance of groovy.lang.Binding.

(*Yeah, I linked to the second edition, even though I’m still using the first edition on a regular basis. That’s still my all-time favorite technical book, so I don’t mind recommending the new version.)

With all that in mind, here’s my JUnit 4 test, written in Groovy for convenience.

package mjg.scripts

import static org.junit.Assert.*

import org.junit.After;
import org.junit.Before;
import org.junit.Test;

class ScriptTests {
    GroovyShell shell
    Binding binding
    PrintStream orig
    ByteArrayOutputStream out

    @Before
    void setUp() {
        orig = System.out
        out = new ByteArrayOutputStream()
        System.setOut(new PrintStream(out))
        binding = new Binding()
        shell = new GroovyShell(binding)
    }

    @After
    void tearDown() {
        System.setOut(orig)
    }

    @Test
    void testScriptWithAssert() {
        shell.evaluate(new File("src/mjg/scripts/script_with_assert.groovy"))
    }

    @Test
    void testScriptWithTrueVariable() {
        binding.ok = true
        shell.evaluate(new File("src/mjg/scripts/script_with_variable.groovy"))
        assertTrue shell.ok
    }

    @Test
    void testScriptWithFalseVariable() {
        binding.ok = false
        shell.evaluate(new File("src/mjg/scripts/script_with_variable.groovy"))
        assertFalse shell.ok
    }

    @Test
    void testHelloWorld() {
        shell.evaluate(new File("src/mjg/scripts/hello_world.groovy"))
        assertEquals "Hello, World!", out.toString().trim()
    }

}

Actually, all my scripts (and the test class) are in a package called mjg.scripts, where mjg stands for Making Java Groovy, of course.

I made the GroovyShell and the Binding instances attributes so I could reuse them. It turns out that by keeping a reference to the Binding, I can still set and get variables using it even though I’ve already instantiated by Groovy shell around it. That’s helpful.

In the set up method (annotated with @Before), I save the current output stream into an attribute so I can restore it later in the tear down method (annotated with @After). That’s not really necessary here, but it seems like a good practice in general.

I’m using a ByteArrayOutputStream to hold the printed data in memory. The System.setOut method requires a PrintStream as an argument, so I wrapped the byte stream inside one.

The first test, testScriptWithAssert, finds the proper file and executes it. That script has the line assert ok in it, after setting the local variable ok to true. If I go into the script and change ok to false, the test fails. This tells me two things:

1. If my scripts are full of assert statements, I can run them as part of a normal build and failures will be reported in the usual way.
2. If an assert fails, there isn’t much I can do to prepare for it in my tests. I can’t, for example, wrap the call inside an assertFalse call. The failure happens before I get back, for one thing.

I basically have to hope that any assert statements in my scripts always succeed, or my tests will fail. Arguably that’s what I want anyway.

The next two tests, testScriptWithTrueVariable and testScriptWithFalseVariable, set the ok variable from the binding, then run the script. The script in question just returns the variable. I check the binding variable at the end of each script, just to prove that I was able to set it properly with the binding.

Finally, I test the “Hello, World!” script. By redirecting standard out to the byte stream, I’m able to capture the print output in a variable. I then invoke the toString method to get the value in the buffer. The trim call is added to handle any whitespace associated with carriage returns, line feeds, etc.

In his blog post, Hamlet used an encoding as the argument to his toString call, claiming that otherwise the output would be different on different platforms. I decided to let Groovy worry about that, so hopefully I won’t get burned by it later.

That’s all there is to it. Now, whenever I add Groovy scripts to a chapter of my book, I make sure to add a test class to check them as well. So far that seems to be working just fine.

Any comments, especially about errors or omissions, are of course welcome. For those who have already purchased the book, (1) you totally rock, and (2) a new chapter will be added to the MEAP early next week, on using Groovy with SOAP-based web services. I’ll blog about that when the new chapter appears.

Note: the source code for this project, including a Gradle build file, is located in my TestingGroovyScripts repository at GitHub.