Starting Grails with Test-Driven Development

October 2015 Blogged by Carl Renstein Rollon

Starting Grails with Test-Driven Development
Currently, our team has been handling 3 Grails applications – two of which were already in production. Using Grails as a full stack web framework enabled us to rapidly develop these apps. In this blog, I’ll share how you can start a new Grails project using Test-Driven Development and Spock.


The versions that I’ll be using are the following:

  • Grails : 3.0.8
  • Groovy : 2.4.4
  • Gradle : 2.3
  • Java : 1.7.0_79

To start, let’s create our Grails application:

Typing grails will activate interactive mode which keeps the JVM running and allows for quicker execution of commands.


Suppose we want to create a domain class Customer, we could do this by:

Notice the generated domain class Customer.groovy and its corresponding unit test class CustomerSpec.groovy.

The @TestFor annotation indicates the class under test and triggers TestMixin AST transform. Specification is the base class for Spock unit tests. Setup() and cleanup() methods are equivalent to JUnit’s @Before and @After, respectively.

Let’s write our first test, say we want our customers to have properties customerName and email. Replace the “test something” method with

When and then blocks describe a stimulus and the expected response. All top level expressions under then are implicitly treated as conditions. Conditions define an expected state, similar to JUnit’s assertions. However, conditions are written as plain boolean expressions, eliminating the need for an assertion API.

To run our test:

It fails. Good! Now let’s add the necessary code to pass our test.

Then re-run it again.

Easy, right? Next, suppose we want to limit our customer names to contain letters and spaces only, and their email addresses to have valid format. Also, we want each property to be unique for every customer. For these, we’ll have to write some constraint tests.

An expect block is similar to a then block but more useful when describing both stimulus and expected response in a single expression. A where block is used to write data-driven feature methods. In the above tests, the where blocks effectively create three “versions” of valid-invalid pairs.

Try to run the tests and you’ll get the following errors:

These lines should make our tests pass:


We’re done for our Customer domain. Let’s generate our controller and views.

As you can see, there are 2 generated groovy files: CustomerController and CustomerControllerSpec, and 4 generated gsp files: edit, create, index and show.

If you view CustomerControllerSpec.groovy, you’ll notice that Grails already created 7 unit test cases: one each for index, create, save, show, edit, update, and delete controller actions. Let’s run them!

Only 2 tests passed while 5 failed. To fix this, notice the first method in CustomerControllerSpec,

We have to implement this method correctly for our Customer domain.

And re-run.

That’s all for our controller. Try to start the application:


For the Test Reports, re-run again all unit tests,

then view your test report:


The source code is available at


Related Posts with Thumbnails

3 Responses to “Starting Grails with Test-Driven Development”

  1. January 5, 2017  -  1:19 pm

    This tutorial is great and helpful. However, the auto generated code for the Controller Spec didn’t explain further. Specifically, the “when” and “then” code on it.

    Thanks đŸ™‚

  2. January 5, 2017  -  2:14 pm
    Carl Renstein Rollon

    Hi Yana,

    Thanks for the feedback! I didn’t explain CustomerControllerSpec.groovy further because the auto-generated methods were already named with descriptive String literals, similar to the when and then blocks.

  3. January 12, 2017  -  9:03 am

    Hi Carl,

    Nice and clear tutorial. Your effort is appreciated.

Leave a Reply

Contact Us