EasyB + Grails Testing

Summary

Description

Overview

Groovy testing implementation of easyb - exposes all of the easyb functionality and an infrastructure to expose the testing functionality that is normally available only to Grails' Unit Testing framework.

The current released version of the Grails easyb plugin works only with versions 1.2 and above of Grails. This is because the Grails testing infrastructure changed significantly between 1.1 and 1.2.

Installation

As with any Grails plug-in, the user can run the install plug-in command to install a plug-in:

grails install-plugin easyb

Where do my files go?

As with other Grails testing frameworks, tests go in your test/unit, test/integration and test/functional sub directories in the test directory. For example, if doing JAX-RS easyb testing, you can put a file called CartResource.story in test/unit and easyb will run that when it is running unit tests.

Both HTML & plain text reports are now stored in the "target/test-reports/" directory inside the grails project.

Running EasyB

After installing, users can use the following commands to run unit, integration, functional or easyb stories.

It is recommended that you suffix your stories and specifications with .story and .specification to make it more clear for others and Grails easyb when trying to run your tests. Ending in one of these suffixes will ensure you easyb tests don't clash with other test plugins.

Best Practice

It is best practice to put your tests (.story or .specification) in the same packages as the classes being tested. The grails easyb plugin will automatically match the tests with their corresponding class. For example:

com.bluetrainsoftware.AuthorController.story will correspond to com.bluetrainsoftware.AuthorController.groovy

com.bluetrainsoftware.AuthorTagLib.story will correspond to com.bluetrainsoftware.AuthorTagLib.story

In addition, controller stories will mock the controller methods & variables available in standard grails controller unit test classes (EX: renderArgs, redirectArgs). The story will include a binding variable called "controller" automatically. In the case of taglibs, a binding variable called "taglib" is included.

It is not crucial to follow this mechanism, these are just convenience methods. If you do not wish to do this, you can use:

grailsTest "controller", "NameOfControllerClass"

to have the plugin automatically mock your controller (use "taglib" for taglibs).

Using Services

There is a keyword that can be used in Specifications and Stories in the integration scope called "inject".

/**
* introduced by Jeffrey C. Erikson
*/

scenario "we should be able to inject services", {
when "requesting the author service bean", {
inject "authorService"
}
then "author service should be callable", {
authorService.doSomething(3).shouldBe "burp"
}
}

In the controller above, there are four basic execution scenarios. The scenarios consists of the following:

No search parameter "query" is passed and the method returns an empty result

Search parameter is passed and search is performed

Search parameter is passed, the "user" search parameter is passed indicating a user only search, and search is performed

Search parameter is passed, exception is thrown while performing a search, an empty result is returned

These scenarios are supported in EasyB story format easily. Validation of these scenarios works the same as in standard Controller unit tests. Developers should utilize the "mockController" method to mock out request parameters and redirectArgs. Developers should also use meta-programming for mocking service & domain methods when necessary. See the SearchController story below for reference: