I had a need of creating a new test harness.  The goal was to use something compatible with the JVM, as some tests will make requests against the private methods used by our developers.

Initially the the goals were:

  • Must be compatible with JVM
  • Need to make API requests for test purposes
  • Save results to a  db
  • Display a UI of result data
  • Tests need to be organized and easily maintained

Nice to have(s):

  • Web Automation

Framework Stack

Since I had to be compatible with the JVM (due to the requirement of having access to private java methods), I decided to not use Ruby (even though I could have used JRuby.)  Instead I went the path of Grails.  Grails will make it very easy for me to set up a UI, Run jobs to kick off tests on a routine schedule (via the Quartz plugin), save results to a db (either the in memory db of Grails or a MySQL db), send email alerts (via the email plugin) and my favorite BDD solution (Cucumber) now is a plugin for Grails.

What makes Cucumber so awesome is it’s so clean to look at (unlock Spock.)  It’s a personal choice, that for me makes sense.  I think other QA people could easily update and maintain a test harness from Cucumber, as opposed to something like GEB+Spock.

As for the “nice to have” of web automation, I decided I could use GEB *shudder* as needed.  I’m not a fan of GEB, and if GEB gets too messy here, I’ll just use the Watir/Ruby solution I currently have.  Testing the front end doesn’t need much back end support – despite the arguments to the contrary, I have seen little improvement in workflow by using a pure JVM web automation methodology than by simply using what works well (i.e. Watir/Ruby) and hitting the front end.  As long as the UI has appropriate handles (like class or name values on links, elements) it should work well.

But I’d give GEB the old college try.  Who knows, maybe it’s better now.  At least we have a plan B (Ruby/Watir) for the “nice to have.”

This vs. Ruby/Watir/Cucumber

Personally, I’d prefer Ruby/Watir/Cucumber over all, but I don’t want to run into compatibility issues later with the private method tests.  I’d prefer we all are in the same paradigm.  So I made the choice to keep to Grails for this.  The application under test is in Grails, and so will be our test harness.

Set Up

I hit a few gotchas with setting up this framework.  You can check out the base framework to get this functionality over on my github. But ultimately I got things smoothed out as long as I did the following:

  1. create a grails app (you may want to run this inside your main grails application. However for starters build a prototype like below to walk through this functionality.  If it works well for you, determine if you need a sep project, or if it should be embedded in the core app itself.  If you are using Grails for the test harness, but the app is Scala or Java… then the decision is made of you – keep it separate.)
  2. in buildconfig.groovy add in the plugin closure: test “:cucumber:0.5.0”
  3. in conf, add a file CucumberConfig.groovy with this in it:

cucumber {

features = [“test/cucumber”]

glue = features


Now Complete the next set of tasks:

  1. in test folder create a sub folder called “cucumber”
  2. in cucumber/ add a .feature file for your first test (i.e. Google_Search.feature)
  3. in cucumber, add a sub folder called steps
  4. in steps folder add a groovy file that will have your steps (i.e. GoogleApi.groovy)
  5. In the steps file you created, be sure to import as follows:
    1. import static cucumber.runtime.groovy.EN.*
    2. note the change from cucumber.api to cucumber.runtime (the documentation still reads cucumber.api)
  6. Disable forking.  
    1. in buildconfig, under grails.project.fork set  
    2. test: false,
    3. Why did we have to set forking false?  Without setting it to false you’ll get some errors currently… Hopefully you’re application won’t need the forking.

Setting UP HTTPBuilder

  1. copy the latest snapshot jars (I had to use version 0.6+ as version 0.5.2 didn’t work for me) into the lib folder of your project – that would be the httpbuilder jar itself, as well as the httpbuilder dependancies.
  2. compile or just do a grails test-app
    1. At this point you don’t need to specify cucumber, but if you want later, you can run grails test-app :cucumber
    2. It should run through your tests and give you some output of failures or any errors with set up.

Example Tests 

Make a feature file with this inside (My feature file looked like this):

Feature: new book entry

As a google user

I want to search google via their api

to validate the search result without a browser


Scenario: new book

Given I query google via their api

Then google will return a result


In Intellij you can simply click into a Given, When or Then line and a little lightbulb will appear.  If you click on it, a drop down opens and says “Create New Step” and you click that and choose the step file or make a new step file.


The step file will have the code that drives those goals, like this:

import groovyx.net.http.HTTPBuilder

import static cucumber.runtime.groovy.EN.*


Given(~’^I query google via their api$’) { ->

// Express the Regexp above with the code you wish you had

http = new HTTPBuilder(‘http://www.google.com’)

html = http.get( path : ‘/search’, query : [q:”Cucumber”])


Then(~’^google will return a result$’) { ->

// Express the Regexp above with the code you wish you had

assert html instanceof groovy.util.slurpersupport.GPathResult

assert html.HEAD.size() == 1

assert html.BODY.size() == 1



This is pretty simple stuff, but you can see the idea of how the test is working.  The step file houses the code that drives the actions.  There is regex that drives the cucumber feature file and determines which step to utilize.  As the steps are called, they execute the functionality within it.


If you’ve used Cucumber before, this is very familiar.


If you’ve used GEB before, the main difference is that Spock would say stuff like:


(some code)


(some code)


Cucumber likes to separate the features from the code that drives them.  The philosophy behind it, allows non technical staff to look at feature files and validate that the tests and requirements are correctly met.  Therefore the business units, marketing units, advertising folks can all chime in and advise if their goals are being tested.


I’ve found that when you drop code and method calls into the actual tests, it causes non-technical staff to just ignore it.  This way they get to contribute without having to understand what’s going on, at the low level.


Well that’s it!  You should have a workable Cucumber test harness, that uses HTTPBuilder for API calls for testing purposes.


No responses yet

Leave a Reply

Your email address will not be published. Required fields are marked *

Recent Comments