DevQA: make your testers happier with Groovy, Spock and Geb
•
3 recomendaciones•3,659 vistas
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
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a DevQA: make your testers happier with Groovy, Spock and Geb
Similar a DevQA: make your testers happier with Groovy, Spock and Geb (20)
Más de Alvaro Sanchez-Mariscal
Más 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