Switch branches/tags
Nothing to show
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
57 lines (33 sloc) 4.21 KB

Playframework Spocktests module

2011-02-20 Peter Lundberg


This module allows running Spock specifications. This provides the possibility to write BDD wrapped junit tests with the expressive power of groovy and still have the tested application be in playframework. This can also be combined with Geb which provides The future of functional web testing.

This has been achieved using a compile-run processes separate from playframeworks test approach. Play! tests are run in the target server processes and does not support Groovy code and the compiler plugin support that Spock needs. Similar roundtrip times can be achieved though as the system under test is run under playframework as usual and only the test code is compiled more traditionally per run and there is no deployment etc.

  • Spocktests vs junit – the BDD approach, tersness, assertions, mocking and error feedback of Spock needs to be tried and is better.
  • Spocktests vs functional – the approach via Geb requires server roundtrip but supports cookies, redirects and can handle authentication which was a major issue for our 1.1 testing. Geb also supplies more that helps writing maintainable tests such as page objects.
  • Spocktests vs selenium – Spock + Geb provided a higher level approach on top of WebDriver’s that is a new API from Selenium. So tests can express any logic and structure the developer needs to make it less brittle. Also Geb’s selectors and page abstractions make for much more maintainable test code.


The module needs to be added to conf/application.conf, then simply run.

$ play test &

To ensure the application is running, in this case with the ‘test’ framework id to help configuration and in the background to allow running other commands and get interleaved console output. But the actual spock tests are not dependant on the play server running. If using web tests this also provided the server to run against, as this is normal a warning is issued if the server cannot be found on localhost. Then assuming you have some spock tests run:

$ play spocktests:run

Which will execute all spock Specifications found under the applications test folder using Junit. These will have been compiled by the groovyc compiler with the application’s classpath and precompiled source on the classpath. This is currently via a embedded apache ant script to re-use existing components. Output is to the screen and the results of the tests are in tmp/spocktests/reports and if a failure occurs a file tmp/spocktests/test.failure exists to ease integration with continuous integration tools.

Alternatively one can select only a few specs by providing a filter for the name of the Spec class. This is done with the following option (which simply defaults to ‘*’):

$ play spocktests:run --specfilter=User*Spec

As the build processes re-uses compiled files, occasionally derived data becomes out of sync with reality. Then this can be reset using:

$ play spocktests:clean

Note that only the HtmlDriver is bundled in the module currently. To use another WebDriver the appropriate jar needs to be in the applications library path.


How to write the specifications is covered in more detail under:


Great kudos to the authors of playframework, geb and spock.

How this moves forward will very much depend on feedback from from users! Some idéas are:

  • provide some samples, eg some groovy yabe tests.
  • Hopefully further integration och ease-of-use can be found.
  • Lessen dependency on external ant
  • This is in use as is in my current project, but may need fixes to easily work in other environments.