The document discusses how a company called Odobo improved their testing process by defining a unified testing framework using Groovy, Spock, and Geb. This allowed both developers and QA engineers to write automated tests in the same framework, eliminating duplicated efforts. Key aspects of the framework included using Gradle for building, Groovy as the programming language, Spock as the testing framework, and Geb for browser automation. It provided benefits like increased code reuse and happier testers across both dev and QA teams.

1. DevQA: make your
testers happier with
Groovy, Spock and Geb
Álvaro Sánchez-Mariscal
Web Architect – odobo
!
@alvaro_sanchez

2. 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.

3. • HTML5 games platform for:
• Game developers.
• Casinos.
• Check out https://play.odobo.com and try
for free!

4. DevOps

5. DevQA
QA

6. Writing tests in Grails
• Unit tests.
• Integration tests.
• Functional tests…

7. Who should write the
functional tests?

8. Writing functional tests
• Normally, the Grails developers will write
them.
• But if you have QA automation
engineers…

9. Problems we found at
odobo and how we
solved them

10. Disclaimer
One size does not fit all

11. Problems we had
• Different frameworks used:
• Developers: Selenium IDE + Grails.
• QA: WebDriver + Java + TestNG.
• Duplicated efforts.
• Zero knowledge sharing and resources
reuse.

12. 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.

13. 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.

14. 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.

15. 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.

16. Fixtures: in Grails

17. Fixtures: in Selenium IDE

18. Fixtures: in Geb

19. 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.

20. Solution: a custom script

21. 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.

22. 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.

23. The browser tool
• Pros:
• Awesome DSL.
• Cons:
• Very difficult to “try and error” your CSS
selectors.
• You end debugging and evaluating
expressions.

24. The browser tool
• Cons:
• Lack of IDE support:

25. Porn for developers!

26. Porn for developers!

27. Documentation
In Confluence

28. Configuration
• Groovy’s ConfigSlurper inside.
• Per environment, like in Grails.

29. Configuration

30. 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.

31. Per environment execution

32. 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.

33. Feature Groups

34. Feature Groups

35. 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.

36. Conclusions
• No effort duplication.
• Everybody works on the same project.
• Effective code reuse.
• CSS selectors are reused via Geb pages /
modules.

37. 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!

38. Current research
• Use Sikuli to automate game testing.
• Sikuli is a visual technology to automate
and test graphical user interfaces using
screenshot images.

39. Sikuli

40. Thanks!
Álvaro Sánchez-Mariscal
Web Architect – odobooo
!
@alvaro_sanchez
alvarosanchez