Chariot Training Classes

Training Courses

I run Chariot's training and mentoring services. We provide training in AngularJS, HTML5, Spring, Hibernate, Maven, Scala, and more.

Chariot Education Services


Chariot Emerging Tech

Learn about upcoming technologies and trends from my colleagues at Chariot Solutions.


Chariot Conferences



Spock and Roo = easier add-on testing, part 1

Hey all...

I've been working on my add-ons. If you're reading this from my website, head over to the Silly Weasel menu and get the repository OBR to install my Spock add-on when trying this.

You are running Groovy in Roo? Shame on you!

Hey, before I was a Roo in Action author, I was a huge fan of Grails. I still am, because Groovy + your favorite APIs is so much more concise to program against than with stock Java. So, one of my backburner projects was getting Groovy to work on Roo.

Roo doesn't like Groovy (yet)

It turns out the reason is AspectJ. Right now, our projects are all compiling against the AspectJ API (version 1.2.x if memory serves). The problem is that Groovy's bytecode is not compatible with AspectJ, at least in terms of getting it to compile in the same Maven compiler step. I looked on the AspectJ timeline, and saw AspectJ 1.5 and 2.0 will support Groovy as a target for weaving. Coolness!

But that doesn't stop us from using it to test!

Yep, that's right. Turns out you can attach the Groovy compiler to your test phase, and it works. By the time your tests are compiling, the main classes have been compiled and weaved with that AspectJ goodness. So your ITD methods are there, and you can use any old testing tool you want to test 'em.

Note, I think you may have issues with my approach, if you are going to use the DataOnDemand testing framework, but so far, it seems like it works well.

My example for the evening - testing with mocks for Add-on Commands

Ok, here's a practical example. My jQueryUI add-on command class delegates the isAvailable and install commands to the Operations Implementation class, JqueryuiOperationsImpl. I wanted to start working up the test coverage for this add-on, because right now I am failing my hudson build due to a lack of test coverage.

So, here is a Groovy Spock specification, which I named JQueryuiCommandsTest.groovy and placed in src/test/groovy (after installing the maven script I'll reference below it). I've even created a Spock Roo add-on for you to use to set this up in your own projects.

package org.sillyweasel.addons.jqueryui

class JQueryuiCommandsTest extends spock.lang.Specification {

    JqueryuiCommands commands
    JqueryuiOperations operations

    def setup() {
        operations = Mock()
        commands = new JqueryuiCommands();
        commands.operations = operations;

    def "when calling availability we defer to implementation" () {
        boolean result = commands.isApiInstallCommandAvailable()


    def "when calling ui availability we defer to implementation" () {
        boolean result = commands.isInstalljQueryUIAvailable()


    def "when calling installjQueryApi we defer to jquery operations method" () {


    def "when calling installjQueryUI we defer to jquery operations method"() {



How did you get this to work?

I basically stole the configuration for Spock and Maven, and tweaked it a bit. Here are the relevant bits of my Maven build:





Roo Add-On Development, Part the Second - Testing XML Configurations

In the last post, we discussed unit testing Roo add-on code. I feel this is just as vital as testing any other piece of Java code, considering that every time you run the command in the container you literally have to boot it, update the OSGi bundle, and then test. The feedback loop is too long to fix little, annoying bugs like not properly parsing an XML document.

Roo "Advanced add-ons" and Configuration

Let's assume we're not stellar coders. Let's even assume that we aren't the best XML developers. I'm shining a bright line at myself here.

With the CoffeeScript add-on, we want to manipulate the pom.xml file - something we don't need a container to do. Roo uses that good ole' built-in JAXP library (and Apache implementation of course). As Ben Alex would say, "stock standard Java." So, we should be able to easily unit test it.

The CoffeescriptOperationsImpl class - under test!

Last blog we showed you how to test the CoffeescriptCommands object, which delegates calls to the CoffeescriptOperations OSGi bean, which is implemented by the CoffeescriptOperationsImpl class. This is where the add-on's work is being done. So, let's test it.

Setting up the test class and Mockito

Like last time, we need to configure Mockito. We'll assume you've read up on that post and have installed the proper dependencies.

We need to test that our operations code works, and that it calls the proper Roo services. So, let's create our bean under test, and then mock the collaborator:

public class CoffeescriptOperationsImplTest {
  private CoffeescriptOperationsImpl coffeescriptOperations; 

  public void setUp() {
    coffeescriptOperations = new CoffeescriptOperationsImpl();
    coffeescriptOperations.projectOperations = 

Again, we manually create our class under test, and configure our mocks, in keeping with typical unit tests of components. I had to widen the visibility of the projectOperations reference to 'friendly' access - so that this class, which lives in the same package as the code under test, can see it and replace it with a mock.

h2. Reviewing our method under test - setup()

Let's look at our setup method:

  public void setup(String coffeeDir, 
                  String outputDirectory, boolean bare) {
    String moduleName = projectOperations.getFocusedModuleName();
    Element coffeePluginElement = getCoffeeScriptPluginElement();
    Document document = coffeePluginElement.getOwnerDocument();

    if (bare) {
      addTextElement(document, coffeePluginElement, "bare", "true");
    } else {
      addTextElement(document, coffeePluginElement, "bare", 

    if (coffeeDir != null && coffeeDir.trim().length() > 0) {
      addTextElement(document, coffeePluginElement, "coffeeDir", coffeeDir);
    } else {
      addTextElement(document, coffeePluginElement, "coffeeDir", 

    if (outputDirectory != null && outputDirectory.trim().length() > 0) {
      addTextElement(document, coffeePluginElement, "coffeeOutputDirectory", outputDirectory);
    } else {
      addTextElement(document, coffeePluginElement, "coffeeOutputDirectory", 

    projectOperations.addBuildPlugin(moduleName, new Plugin(coffeePluginElement));

It's clear that we have a LOT of branches in this code, but that's because we're taking input from our command itself. I'll lie here, and tell you that I've written tests against all of these branches, but again, I said I'm lying - and in a further lie, I'll tell you that "I'm gonna get to it!" However, here's why lying doesn't help - I'm sure I have bugs in this code, and I really need to verify it all.

Oh, and I was thinking - I have a few private methods to help me keep the code organized and modular... Perhaps I should test those too but that leads the way of code smell... Interesting read BTW.

Reviewing the tasks in the method

Ok, the method does a few things:

1. Asks a helper method for the Configuration XML file as a basis for the Maven plugin.
2. Does a couple of gyrations so that we can maniuplate the plugin nodes with the DOM API - since Roo's Maven object model is essentially a thin wrapper around the XML API we have to think more in XML. This is something I'll be exploring in the future.
3. Sets the options the user passed in.
4. Adds the build plugin to the Maven build.

Ultimately, though, we need to see if:

1. Given a call to setup(), and the appropriate parameters,
2. Does the Plugin contain the proper information

Our test method for the setup process


  public void testSetupCoffeescript() {


    // a way for Mockito to grab passed input parameters for testing
    ArgumentCaptor<Plugin> pluginCaptor = 

    // invoke our method
    coffeescriptOperations.setup("baz", "bar", false);

    // did we call addBuildPlugin? Also, notice we capture what the
    // method passed to the mocked projectOperations.addBuildPlugin method
    // for the plugin XML Element code
       .addBuildPlugin(any(String.class), pluginCaptor.capture());

    // Since the plugin has been called and we've captured the method's 
    // second argument, we'll pluck it out and take a gander...
    Plugin coffeescriptPlugin = pluginCaptor.getValue();

    // make sure they passed something!

    // checks against the model
    Assert.assertEquals("false", coffeescriptPlugin.getConfiguration()

    Assert.assertEquals("bar", coffeescriptPlugin.getConfiguration()

    Assert.assertEquals("baz", coffeescriptPlugin.getConfiguration()

Mockito's ArgumentCaptor

I guess this is really a testing tools article, rather than a Roo article.

The ArgumentCaptor API is really useful to see what the values were for a mock that was called by your class under test. This is a way to verify that we were passing in the right plugin configuration to our Roo projectManager, which, after all, we aren't testing. That's the Roo team's job!


Looking at it from a distance, Roo is just a Java platform that generates, manipulates and configures applications. So it can really do anything. However, rather than testing by re-deploying 10 times, we can run a fast Junit test 10 times instead.

If you go to my Silly Weasel link at the top of the blog page, you'll see the OBR URL for getting my Coffeescript, jQuery and (soon) Site add-ons. You can browse my maven repository (the same URL without the repository.xml ending) and grab the source for anything I've released.

Please send me comments if you'd like to add to this discussion.




Roo add-on development - how to unit test configuration changes

I'm working on updates to several Roo add-ons, which I am going to be pushing out to the Roo repository soon. Here are some challenges and how I overcame them.

The add-on command marker interface

This add-on sets up Coffeescript using a Maven plugin. Here is the add-on source:

package org.sillyweasel.addons.coffeescript;

import org.apache.felix.scr.annotations.Component;
import org.apache.felix.scr.annotations.Reference;
import org.apache.felix.scr.annotations.Service;

public class CoffeescriptCommands implements CommandMarker { 

   * Get a reference to the CoffeescriptOperations from the underlying OSGi
   * container
  CoffeescriptOperations operations;

  @CliAvailabilityIndicator({"coffeescript setup"})
  public boolean isSetupCommandAvailable() {
    return operations.isSetupCommandAvailable();

  @CliAvailabilityIndicator({"coffeescript remove", "coffeescript addjoinset", 
    "coffeescript removejoinset", 
    "coffeescript listjoinsets"})
  public boolean isCoffeescriptInstalled() {
    return operations.isPluginInstalled();

  @CliCommand(value = "coffeescript setup", 
     help = "Install the CoffeeScript compiler")
  public void setup(
    @CliOption(key = "outputDirectory", mandatory = false,
        unspecifiedDefaultValue = "${}") String outputDirectory,
    @CliOption(key = "coffeeDir", mandatory = false,
        unspecifiedDefaultValue = "src/main/webapp/scripts",
        specifiedDefaultValue = "src/main/webapp/scripts") String coffeeDir,
    @CliOption(key = "bare", mandatory = false,
        unspecifiedDefaultValue = "false",
        specifiedDefaultValue = "true") boolean bare) {

    operations.setup(coffeeDir, outputDirectory, bare);

  public void addJoinSet(
      @CliOption(key = "joinSetId", mandatory = true, specifiedDefaultValue = "main")
      String joinSetId,
      @CliOption(key = "includes", mandatory = true, 
         help = "comma-separated list of search paths for javascript files to include")
      String includes,
      @CliOption(key = "excludes", mandatory = true, 
         help = "comma-separated list of search paths for javascript files to exclude")
      String excludes) {

    // TODO - set up the command


  @CliCommand(value = "coffeescript remove", help = "Remove the coffeescript compiler")
  public void remove() {

Some of this I haven't written yet (hence the TODOs) but the rest is fleshed out and I'll be going over it later.

Task #1 - Roo addons don't include JUnit?

Right now, no. (ROO-3161) However, you can just add it yerself. I'm using Mockito for mocking (more about that later) as well as messing around with those lovely Hamcrest matchers:


Task #2 - You need to widen the visibility of the Roo-injected OSGi objects to mock them

Because we want to unit test our add-ons without firing up an OSGi container, we will need to mock things. I'm using Mockito, an excellent mock and spy library. But I can't get to the injected objects, and the test I'm going to show here has to make a "mockery" of the ProjectOperations Roo service. It is defined this way in the code of the Operations implementation class:

private @Reference ProjectOperations projectOperations;

The problem with this is that I can't just use Mockito's mocking method to access and fake it out. So, I widened to friendly scope, which allows access from the same package. I guess the better way would maybe have been to create a getter but then I'm exposing it in a wider range than just the add-on's specific package:

@Reference ProjectOperations projectOperations;

Task #3 - how to test the Command Marker

Ok, so the first thing I want to do is make sure my Command Marker calls the proper command implementation methods. First up, we widen the reference to our CoffeescriptOperations variable:

@Reference CoffeescriptOperations operations;

Then, we write a method that uses Mockito to mock calls to the operations object. This is the test class:

package org.sillyweasel.addons.coffeescript;

import junit.framework.Assert;
import org.junit.Before;
import org.junit.Ignore;
import org.junit.Test;

import static;
import static org.hamcrest.MatcherAssert.assertThat;
import static org.mockito.Mockito.*;

public class CoffeescriptCommandsTest {

  private CoffeescriptCommands commands;

  public void setUp() {
    commands = new CoffeescriptCommands();
    commands.operations = mock(CoffeescriptOperations.class);

  public void testIsPluginInstalled() {
    assertThat(commands.isCoffeescriptInstalled(), is(false));

  public void testIsCoffeescriptSetupAvailable() {
    assertThat(commands.isSetupCommandAvailable(), is(true));

  public void testIsCoffeescriptRemoveAvailable() {
    assertThat(commands.isCoffeescriptInstalled(), is(true));
    verify(commands.operations, times(1)).isPluginInstalled();

  public void testInstallCoffeeScript() {
    commands.setup("foo", "bar", true);
    verify(commands.operations).setup("foo", "bar", true);

  public void testRemoveCoffeeScript() {

  public void testFileSets() {;

See how I'm using some Hamcrest matchers in there? I like assertThat(..., is()) syntax.

So now we know that our command marker is actually calling the delegate methods when it is being invoked. And we're on our way, able to mock anything we want to, provided we widen the scope a bit from a 100% internal private member variable.

In our next post I'll show you how to test the actual XML configuration. That one is going to be rather large so I'll separate it into another one.


Didn't make it to Philly Emerging Tech? Watch the sessions online!

Let's say you didn't get a ticket to the Emerging Technologies for the Enterprise conference, but you really, really wanted to go.

We're happy to oblige.

Visit our Emerging Technologies 2012 Screencast microsite. RSS readers, subscribe here.


Don't call names - Roo's Tag with a tag problem

Eureka, ish..

I was trying to find time to debug a problem that's been on my backlog for a while, and someone else ran into it. A reader over on the Manning Spring Roo in Action forum was getting hit with a 400 invalid request error when trying one of the samples from the book (the many-to-many example).

A while back, I ran into this problem - my m:m arrangement was between Courses and Tags, and the field name of the actual tag in the Tag entity was called 'tag'. When I did this, I got the same error. Someone hit it in the forums, we renamed it to 'name' and committed our code, and I forgot about it for a while.

My theory was that the type converters somehow were generated wrongly. Nope, I have a " target="_blank" class="offsite-link-inline">JUnit test to review that does it properly, so that's not the problem.

Actually, the problem is with the type conversion, but it's not the fault of the Roo code for type converters (to my knowledge so far). They are just doing what they are supposed to do.

The REAL Problem

First of all, my theory on the bad type converters was wrong. I proved it by writing a set of tests to make sure I a) understood the true workings of the generated type converters and b) that they worked. In the next edition of Roo in Action I think I need to devote some time to these. See the attached sample at the end to see my tests. Here is how they work (example - the tag):

Type Conversions

  • Convert an object -> a single line String representation as a default label for a given dropdown entry. (converterFactory.getTagToStringConverter())
  • Hydrate a Tag via a String representation of the key (converterFactory.getStringToTagConverter())
  • Hydrate a Tag via a primary key value (converterFactory.getIdToTagConverter())

All of these work just fine when tested individually, which they should.

The Tag to String converter is used in dropdowns for the many-to-many relationship, so that when the tag editing screen (which owns the relationship) allows a user to select one or more courses, it just shows the field values separated by spaces.

So, now what?

Spring MVC creates forms with a set of assumptions, including the fact that the form will be of a certain bean instance root. This is provided by specifying the modelAttribute in Spring MVC, but since Roo does this for us, we aren't in charge of that in a scaffolded UI.

Here is the create.jspx file for reference.

The scaffolded value is generated by create.tagx, which uses this code:

<form:form action="${form_url}" method="POST"
   modelAttribute="${modelAttribute}" enctype="${enctype}" 
   onsubmit="${jsCall}"> ...

The essential problem I think we're running into with the samples the way they are put together is:

  • The "bean context" / model attribute name of the form being submitted is expected to be 'tag'
  • The form is submitting fields in this form with names such as description, id, and also tag
  • Spring MVC is spitting nails on the fact that you have tag.tag in your request. It wants to convert the nested tag into another Tag object, by hydrating it (probably to support recursive relationships or something). Well, it takes your String for the tag label and tries to take it through idToTagConverter() which fails on a numeric parse.

How to fix For now, avoid using the entity name as a field name in a given entity. I need to do more extensive testing to see why this is happening. This is something that I should know by heart, I guess, but I've been wrestling with other areas of Java and Roo and haven't been as connected to the web forms as I used to be.

If anyone wants to take this on, I have posted the code sample in the original Manning thread (look on the second page) with the junit tests included. Just create a course, then create a tag with the 'tag' field of any alpha value.

[b]The sample test[/b]

I created a spring junit test to check my assumptions (I imported hamcrest-all for matching support to make the assertions readable quickly, the pom includes org.hamcrest:hamcrest-all:1.1).