En todos los proyectos de software, habitualmente tenemos que dedicarle mucho esfuerzo al testing. A asegurarnos de que los productos que desarrollamos funcionen correctamente y, aunque sabemos que es imposible asegurar que no tenga ninguno, sí debemos procurar que tengan el menor número de errores posible. Debemos escribir código que pruebe nuestro código, automatizar al máximo nuestros tests para hacerlos repetibles y poder conocer lo antes posible cuando hemos roto algo, porque no nos engañemos, de vez en cuando rompemos algo. Si además de escribir tests, lo hacemos antes, estaremos escribiendo antes un cliente que usará nuestro API que la implementación. De ese modo la cobertura de test sobre nuestro código crece exponencialmente y los mismos tests nos guiarán a que nuestro diseño mejore practicando las refactorizaciones pertinentes; En definitiva estaremos practicando TDD. En esta charla no pretendo sentar cátedra sobre como hacer testing, simplemente compartiré como lo hago yo en mis proyectos Grails, desde los unitarios subiendo hasta la interfaz de usuario.

1. Testing en proyectos
Grails del día a día
Greach - Madrid - Enero 2013
viernes, 25 de enero de 13

2. ¿Quién soy?
• @dani_latorre
• Jobsket, elDisparate.de, Minchador...
• Freelance, contractor, consultor...
• CachiruloValley crew
viernes, 25 de enero de 13

3. viernes, 25 de enero de 13

4. Freelance ¿ágil?
• Trabajo con un equipo, siempre
• Hay personas que usarán mi software
• Me creo el manifiesto
• Trato de aplicar los principios
viernes, 25 de enero de 13

5. Manifiesto ágil
• Individuos e interacciones sobre procesos y herramientas
• Software funcionando sobre documentación extensiva
• Colaboración con el cliente sobre negociación contractual
• Respuesta ante el cambio sobre seguir un plan
viernes, 25 de enero de 13

6. ¿Por qué testeo?
• Hacer cambios con mayor confianza
• Descubrir un error cuanto antes
• Tener trazabilidad del origen de error
• Escribir mejor código
• Mejorar la calidad
viernes, 25 de enero de 13

7. Tipos de tests
• Unitarios (JUnit y Spock)
• Integración (JUnit y Spock)
• Funcionales (Spock + Geb)
• Con usuarios (Manuales + analítica web)
viernes, 25 de enero de 13

8. Estilo de testing
• Testear comportamientos, no métodos
• Nombres autodocumentados
• Pensarlos en un estilo de aceptación
viernes, 25 de enero de 13

9. TDD
• Escribe un test
• Ejecuta los tests y mira si falla
• Escribe el código para que pase el test
• Comprobar que todos los tests pasan
• Limpia y refactoriza
viernes, 25 de enero de 13

10. Red-Green-Refactor
viernes, 25 de enero de 13

11. TDD as if you meant it
• Escribe un test lo más pequeño posible
• Ejecuta los tests y mira si falla
• Implementa la solución en el propio test
• Refactoriza duplicaciones. Introduce
métodos y clases sólo cuando mejore el
diseño del código.
viernes, 25 de enero de 13

12. Unit testing
• Los más rápidos y con mayor trazabilidad
de errores
• Sin el entorno de Grails
• Domain, services, muchos controllers y
algunos taglibs
• Groovy y Java “helpers”
viernes, 25 de enero de 13

13. Mocks & stubs
• @TestFor
• @Mock / mockDomain
• ExpandoMetaClass
• mockFor
• Spock mocks
viernes, 25 de enero de 13

14. Domain unit test
• Demo
• https://github.com/danilat/CachiruloHub/
blob/master/hub/test/unit/hub/
TagTests.groovy
• https://github.com/danilat/CachiruloHub/
blob/master/hub/test/unit/hub/
CompanyTests.groovy
viernes, 25 de enero de 13

15. Controller unit test
• En ocasiones uso los “baratos” del CRUD
• Demo
viernes, 25 de enero de 13

16. Service unit test
• Demo
• https://github.com/danilat/bitly-shortener/
blob/master/test/unit/com/grails/plugins/
bitly/BitlyServiceTests.groovy
viernes, 25 de enero de 13

17. TagLib unit test
• Demo
• https://github.com/danilat/bitly-shortener/
blob/master/test/unit/com/grails/plugins/
bitly/BitlyTagLibTests.groovy
viernes, 25 de enero de 13

18. Integration testing
• Pruebo más cosas (db, mensajería...)
• Más lentos y menor trazabilidad de error
• Algunos controllers, services y taglibs
• Casos difíciles de testear unitariamente
¿mal diseñados?
viernes, 25 de enero de 13

19. Functional testing
• Test de aceptación desde el navegador
• Los más lentos y que menor trazabilidad de
error dan
• Son muy débiles
• Uso para pocos escenarios por
funcionalidad
viernes, 25 de enero de 13

20. Spock + Geb
• Prueba de aceptación > Spec
• Page Object Pattern, encapsula páginas y
ayuda a fortalecer test
• Sintaxis “tipo” jQuery
• Demo
viernes, 25 de enero de 13

21. Continuous testing
• Auto Test
• Guard
• Integración continua (Jenkins)
viernes, 25 de enero de 13

22. Análisis de código
• CodeNarc Plugin
• Test Code Coverage Plugin (Cobertura)
• Otros para Java: Findbugs, PMD,
Checkstyle...
viernes, 25 de enero de 13

23. ¿Añadir funcionalidad?
• Historia/s de usuario
• Mockup/prototipo de baja resolución
• Tests unitarios/integración
• Tests funcionales
• Tests con usuario (si se hacen)
• Despliegue y analítica
viernes, 25 de enero de 13

24. ¿Preguntas?
viernes, 25 de enero de 13

25. ¿Preguntas?
• dani@danilat.com
• www.danilat.com
viernes, 25 de enero de 13