DevQA: make your testers happier with Groovy, Spock and Geb (Greach 2014)

2,306 views

Published on

Writing functional tests using Geb in a Grails application is fine for a development team. But when you have QA automation engineers, giving them access to the Grails app might not be the best solution (specially when they belong to a different team).
So the same way DevOps allow developers and sysadmins collaborate together, let’s talk about DevQA, and make them happy using a framework stack powered by Groovy.

Besides above considerations, in this talk I will show a live example on how to setup an independent project for functional tests using Gradle, Groovy, Spock and Geb.

Published in: Software, Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,306
On SlideShare
0
From Embeds
0
Number of Embeds
461
Actions
Shares
0
Downloads
14
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

DevQA: make your testers happier with Groovy, Spock and Geb (Greach 2014)

  1. 1. DevQA: make your testers happier with Groovy, Spock and Geb Álvaro Sánchez-Mariscal Web Architect – odobo ! @alvaro_sanchez
  2. 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. 3. • HTML5 games platform for: • Game developers. • Casinos. • Check out https://play.odobo.com and try for free!
  4. 4. DevOps
  5. 5. DevQA QA
  6. 6. Writing tests in Grails • Unit tests. • Integration tests. • Functional tests…
  7. 7. Who should write the functional tests?
  8. 8. Writing functional tests • Normally, the Grails developers will write them. • But if you have QA automation engineers…
  9. 9. Problems we found at odobo and how we solved them
  10. 10. Disclaimer One size does not fit all
  11. 11. Problems we had • Different frameworks used: • Developers: Selenium IDE + Grails. • QA: WebDriver + Java + TestNG. • Duplicated efforts. • Zero knowledge sharing and resources reuse.
  12. 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. 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. 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. 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. 16. Fixtures: in Grails
  17. 17. Fixtures: in Selenium IDE
  18. 18. Fixtures: in Geb
  19. 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. 20. Solution: a custom script
  21. 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. 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. 23. The browser tool • Pros: • Awesome DSL. • Cons: • Very difficult to “try and error” your CSS selectors. • You end debugging and evaluating expressions.
  24. 24. The browser tool • Cons: • Lack of IDE support:
  25. 25. Porn for developers!
  26. 26. Porn for developers!
  27. 27. Documentation In Confluence
  28. 28. Configuration • Groovy’s ConfigSlurper inside. • Per environment, like in Grails.
  29. 29. Configuration
  30. 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. 31. Per environment execution
  32. 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. 33. Feature Groups
  34. 34. Feature Groups
  35. 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. 36. Conclusions • No effort duplication. • Everybody works on the same project. • Effective code reuse. • CSS selectors are reused via Geb pages / modules.
  37. 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. 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. 39. Sikuli
  40. 40. Thanks! Álvaro Sánchez-Mariscal Web Architect – odobooo ! @alvaro_sanchez alvarosanchez

×