Running Geb specs using a separate driver profile to test mobile views in Grails

We’re currently building mobile views for our grails application using jQuery mobile and the Spring mobile plugin. As such, we wanted to add a set of mobile tests in Geb to run in parallel with our application’s functional tests.

In this post, I show how you can set up a separate webdriver profile for a subset of your spock/geb functional tests. 

Slides from ‘A year in the life of a Grails startup’

Here is a copy of our slides from the Grails Exchange. You can watch our talk here.

You can view the entire talk here.

Suggestions to keeping Grails one step ahead – a wishlist

At the Grails Exchange, Marc Palmer gave an excellent talk about keeping Grails one step ahead. This talk resonated a bit with the work we been doing in Secret Escapes for the last few months.

After having a little think about it, I feel like there are a few other things that would be nice to have to make Grails a easier choice for developers:

A Script to run Grails Functional Tests in Parallel

The following post is about our effort to set up a way to run functional tests in Parallel for our grails application. It contains a script that will run functional tests based on X-number of instances of the application server, creating the right databases and the proper environment.

Replacing the Groovy execute() method with one that prints output while the process is running

We are writing a small script to help us run our grails functional tests in parallel.

One of the issues we are running into with Groovy’s execute() method and its online examples is that the output from the process is not available until the process is finished.

When running Grails functional tests, we want to see the results right away in the console to debug things that are going wrong.

The solution we found was to use the Java ProcessBuilder task instead.

So instead of

myCommand.execute()

in Groovy, use the following wall of code:

ProcessBuilder builder = new ProcessBuilder( myCommand.split(' ') )

builder.redirectErrorStream(true)

Process process = builder.start()

InputStream stdout = process.getInputStream ()
BufferedReader reader = new BufferedReader (new InputStreamReader(stdout))

while ((line = reader.readLine ()) != null) {
   System.out.println ("Stdout: " + line)
}

You could probably change this so that it replaces the groovy metaclass methods, but it’s a start.

Grails quick tip: Testing Spock Interactions wrapped by the Executor plugin

We ran into an interesting issue today working with Spock, Grails and the executor plugin.

The executor plugin allows you to move tasks that might be long running into the background of your application.

In this post, I will show you how to unit test spock interactions wrapped inside the runAsync methods provided by the plugin.

Six ways to become a better Grails programmer

1. Read the Groovy books

Groovy is the heart of Grails, but it is surprising how easy it is to get by writing code the Java way.

I think it was four months after I started writing code in Grails that I started looking at the Groovy books, and they definitively helped me improve the code I was writing tremendously.

• Venkat Subramaniam’s Programming Groovy – Good chapters on metaprogramming.
• Dierk Koenig’s Groovy In Action, 2nd Edition, MEAP – Excellent for understanding newer concepts like AST transformations.

Migrating from the Grails UI-performance plugin to resources plugin.

The UI-performance plugin has been a standard for managing images, css and javascript files for many grails applications. In the upcoming Grails 2.0 release, however, it seems that the recommended way of managing resources is via the Resources plugin.

Many of the posts on the web ( like this one, or this one )describe how to get started with the Resources plugin from scratch. However, chances are that your project already uses UI-performance. How easy is it to migrate an existing project to use Resources?

In this post, I would like to document the steps we took to migrate our Grails project from the UI-performance plugin to the new resources plugin.

Job specs that make your team shine – building a spec with your development team

Secret Escapes is a great place to work for. Our team is multi-cultural and fun, we use the latest tools in the Grails ecosystem, and we work very well together.

However, I always found it difficult to present this to job applicants. Our initial job postings where hastily copied from other job postings and failed to present our culture of sharing and collaboration.

We recently had an opening for a Junior Grails Developer, and I thought it would be interesting to have the team help me come up with a new job spec that would reflect the company they would be working with.

After a couple of hours, we came up with a new job description that we think presented our development team much better.

In the old spec, we focused a lot on the technology side of things. For developers working in the Java world, having the ability to play with Grails and Groovy is certainly very appealing. But this alone would not convince me to send my CV over to a new company. We tried to make it very clear about the type of people we wanted and the type of team we are.

Some useful Geb / Grails / IntelliJ configuration parameters

Our team has been looking at making our functional tests better by improving the way in which we use Geb.

In this post, I want so summarize some useful configuration parameters for working with Grails, Geb and IntelliJ idea.