DevQA: make your testers happier with Groovy, Spock and Geb
•
3 gostaram•3,659 visualizações
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.
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a DevQA: make your testers happier with Groovy, Spock and Geb
Semelhante a DevQA: make your testers happier with Groovy, Spock and Geb (20)
Mais de Alvaro Sanchez-Mariscal
Mais de Alvaro Sanchez-Mariscal (20)
Último
Último (20)
DevQA: make your testers happier with Groovy, Spock and Geb
- 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. • We are hiring! • http://bit.ly/odobo-grails-job
- 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.
- 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: • Low IDE support.
- 23. The browser tool • Pros: • Awesome DSL. • Cons: • Very difficult to “try and error” your CSS selectors. • You end debugging and evaluating expressions.
- 27. Configuration • Groovy’s ConfigSlurper inside. • Per environment, like in Grails.
- 28. Configuration
- 29. 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. 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.
- 32. Feature Groups
- 33. Feature Groups
- 34. 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.
- 35. Conclusions • No effort duplication. • Everybody works on the same project. • Effective code reuse. • CSS selectors are reused via Geb pages / modules.
- 36. Developing SPI apps with Grails and Angular JS This afternoon, 14:00
- 37. Thanks! Álvaro Sánchez-Mariscal Web Architect – odobo ! @alvaro_sanchez