Since my last post in 2011, I have been a backend services test developer, as I figure that after this services stint, it'll be a good E2E experience to get back into mobile/front-end of the services I worked on (and 'eat my own dog food'). The product that piqued my interest was going to be a Grails based application and I have to call the shots for testing. This blog recaps what I've learnt in the process (2012-2014) and the testing decisions made.

Cool things about Grails

  • Convention over configuration (or coding by convention)
    • Less code or configs - by dictating what goes where and how files are named, this eliminates a lot of specifications a developer has to write, e.g. directories such as controllers, domain, services, conf, and views distinguishes the code content.
    • Built-in commands - simple grails commands such as run-app, test-app, war without any configuration is made possible by the coding convention specified.
  • H2 in-memory database
    • Ramp up - both development and testing can get jump-started instantly with a default in-memory database that comes with grails. This means there is no need to setup a database or figure out network connectivity, just store data with H2 and test with the actual database when it's ready and available.
    • Ease of use - configuration cannot be simpler with Config.groovy.
    • Fast execution - tests run blazingly fast with H2 and we can run thousands of unit AND functional regression tests all under 5 mins.
    • Testability - our scrum team supports H2 in-memory database for testability purposes in addition to production database provider.
  • GORM
    • Grails Object Relational Mapping using Hibernate 3 to create, update, and access domain objects in the database with ease and much readable code and commands. E.g. create-domain-class command will generate code for the domain object in Groovy as well as a automatic database tables creation if specified in dataSource section of application.groovy
    • Database migration plugin - Schema changes from release to release are automatically supported with grails database migration plugin (using LiquidBase). With a simple grails command , dbm-generate-changelog, a changelog.groovy file is generated. We have done many schema additions, updates and deletes with this plugin successfully.
  • Groovy
    • After coding in Groovy for a while, try coding in Java with say arrays, strings and file I/O. You may experience some pain and frustration.
    • Closures - Java 8 introduced lambda expressions similar to Groovy's closures to some extent.

Testing decisions

  • Groovy over Java
    • There are many advantages to write test code in the same language as source code. Productivity, for example, is gained when scrum team have test code in the same repository as source code, and can clone from a same grails CI pipeline. Furthermore, scrum team can easily run, fix and add tests without additional steps or setup. Best of all, there's is no excuse for anyone not to run tests before checking in code.
  • RestAssured over HTTPBuilder
    • HTTPBuilder is more of a library and RestAssured is testing framework that integrates both BDD, and test verifications. I'll be speaking on this topic in detail at StarWest 2015.
  • Spock
    • My favorite feature of Spock is the equivalent TestNG data provider but in a form of data table. Expected outputs can be further distinguished from input data with the double pipe notation.
    • Spock has clear distinct test steps known as blocks to make tests readable. The blocks are setup, when, then, expect, cleanup.
Btw, this blog is not meant to promote Grails or Groovy in anyway. There are other considerations such as performance, plugins maturity/support and other emerging frameworks (e.g. play) that you should take into account. Nothing is perfect, so have fun learning and improvising!