DevQA: make your testers happier with

Groovy, Spock and GebÁlvaro Sánchez-Mariscal

Web Architect – odobo !

@alvaro_sanchez

About me

• Passionate software developer.

• Founded Salenda in 2005.

• Co-founded Escuela de Groovy in 2009.

• Groovy/Grails lover since 2007.

• Working now at Odobo as Web Architect.

• HTML5 games platform for:

• Game developers.

• Casinos.

• Check out https://play.odobo.com and try for free!

DevOps

DevQA

QA

Writing tests in Grails

• Unit tests.

• Integration tests.

• Functional tests…

Who should write the functional tests?

Writing functional tests

• Normally, the Grails developers will write them.

• But if you have QA automation engineers…

Problems we found at odobo and how we

solved them

Disclaimer

One size does not fit all

Problems we had

• Different frameworks used:

• Developers: Selenium IDE + Grails.

• QA: WebDriver + Java + TestNG.

• Duplicated efforts.

• Zero knowledge sharing and resources reuse.

The approach

• Define a unified and shared testing framework for Dev and QA.

• For any kind of web application.

• Have N+M testers instead of N Devs and M QAs.

The framework

• An independent project using:

• Gradle for building and running.

• Groovy as programming language.

• Spock as testing framework.

• Geb as browser automation tool.

• With some custom features.

Independent project• Pros:

• Easier for non Grails developers.

• Prevents QA from touching anything else.

• We can now write tests for any application.

• Cons:

• You need to think about how to feed your app with fixture data.

Fixtures

• First attempt: GORM standalone. It didn’t work :(

• We already had a fixture controller to allow Selenium IDE invocations via HTTP.

• It was easy to reuse in the new project.

• This requires to have the Grails application running.

Fixtures: in Grails

Fixtures: in Selenium IDE

Fixtures: in Geb

Jenkins gotchas

• There are 2 projects, so:

1. Run Grails app.

2. When it is up, launch the tests.

3. Tear down everything at the end.

Solution: a custom script

The language

• Pros:

• Strong knowledge within the Grails team.

• Less verbose than Java (aka “We are not writing fucking semicolons!”).

• Cons:

• Learning curve for QA automation engineers.

The testing framework

• Pros:

• Beautiful DSL, even better combined with Geb.

• Cons:

• People that only have done JUnit may need more time to get used to BDD style.

The browser tool

• Pros:

• Awesome DSL.

• Cons:

• Very difficult to “try and error” your CSS selectors.

• You end debugging and evaluating expressions.

The browser tool

• Cons:

• Lack of IDE support:

Porn for developers!

Porn for developers!

Documentation

In Confluence

Configuration

• Groovy’s ConfigSlurper inside.

• Per environment, like in Grails.

Configuration

Per environment execution

• We have 2 kinds of environments:

• With fixtures enabled, like localhost.

• Live environments, like QA or Staging.

• Implemented as a Spock extension.

Per environment execution

Feature Groups

• A port of TestNG’s test groups.

• Used by QA team to group tests around business features, and not just single user stories.

• Eg: @FeatureGroup([‘operatorMarketplace’])

• Implemented as a Spock extension.

Feature Groups

Feature Groups

Conclusions

• Happier Grails developers.

• The whole solution is better than Selenium IDE.

• Happier QA’s.

• Learning a lot of new stuff.

• Not feeling alone anymore.

Conclusions

• No effort duplication.

• Everybody works on the same project.

• Effective code reuse.

• CSS selectors are reused via Geb pages / modules.

Conclusions

• Groovy is now being used also for REST API testing.

• Java developers are also being exposed to Groovy.

• … and one day it will take over the world!

Current research

• Use Sikuli to automate game testing.

• Sikuli is a visual technology to automate and test graphical user interfaces using screenshot images.

Sikuli

Thanks!Álvaro Sánchez-Mariscal

Web Architect – odobooo !

@alvaro_sanchez alvarosanchez