Skip to end of metadata
Go to start of metadata

I was curious how the abstract BuildSupport class is working that does all those great things for e.g. the SwingBuilder and AntBuilder.

So I wrote the following Groovy Test that exposes its behaviour:

The SpoofBuilder is a sample instance of the abstract BuilderSupport class that does nothing but logging how it was called, returning 'x' for each node.

The test sections call the SpoofBuilder in various ways and the log reveals what methods were called during the "Build".

This test allowed me to verify my assumption on how the builder pattern works here. I used this knowledge to write a specialized AntBuilder for

Error formatting macro: link: java.lang.IllegalArgumentException: Link needs a name and a URL as arguments.

. This "MacroStepBuilder" allows using the Canoo WebTest "steps" (that walk through a webapp for testing) from Groovy Code. Groovy has now become a first-class citizen in the

Error formatting macro: link: java.lang.IllegalArgumentException: Link needs a name and a URL as arguments.


When writing the above test I stumbled over a few things, here are two of them:

  • I was not able to write a fully fledged subclass of GroovyTestCase with separate methods for the various tests. I couldn't find out how to make the SpoofBuilder an inner class of my TestCase. I would very much appreciate help on this.
  • Coming from Ruby I expected the << operator on Strings to operate on the String itself (like it does on Lists) rather than giving back a modified copy. It appears to me that << on Strings and on Lists is not consistent. Same with the "+" operator.

What I especially appreciated:

  • == on Lists is clear and compact
  • display of evaluated expression when assert fails saves a lot of work when writing assertions. Most of the time you need no extra message.

keep up the good work!

  • No labels


  1. In Groovy, as in Java, Strings are immutable. This makes interworking with Java code very easy. However it does mean that operations on Strings have to produce new instances rather than modifying the existing instance.

    John Wilson

  2. I understand you trade interoperability with Java for consistency inside Groovy. But there may be a solution...
    to clarify my point:

    There are lots of commonalities with String and List like

    and even more like behaviour of the 'each' method.


    works fine while


    It seems to that the 'leftShift' method is expected to modify the receiver object but the implementation on String just doesn't allow that.

    I would propose to remove (or deprecate) that method from String. One can still use the + operator to achieve the old result. And + is expected to leave the receiver object unchanged (question).

    BTW: I very much like the Ruby notion of trailing ! chars in method names that modify the receiver (I understand that this is not possible for operators). So leftShift! would be a such a name.

  3. After trolling the web and various books looking for examples of "how" to use BuilderSupport, I could find nothing to-the-point. Everything either missed the mark or was vague and overly-complicated. The idea in this post is simple and yet powerful (i.e., elegant): Log the calls to the Builder's various methods and see what happens. I duplicated and modified this approach, and finally was able to get a handle on "how" BuilderSupport actually works. In no time at all, I had a working Builder put together, building an object tree. Thanks for a very useful post!