testing en proyectos grails del día a día. greach 2013
DESCRIPTION
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.TRANSCRIPT
Testing en proyectos Grails del día a día
Greach - Madrid - Enero 2013
viernes, 25 de enero de 13
¿Quién soy?
• @dani_latorre
• Jobsket, elDisparate.de, Minchador...
• Freelance, contractor, consultor...
• CachiruloValley crew
viernes, 25 de enero de 13
viernes, 25 de enero de 13
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
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
¿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
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
Estilo de testing
• Testear comportamientos, no métodos
• Nombres autodocumentados
• Pensarlos en un estilo de aceptación
viernes, 25 de enero de 13
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
Red-Green-Refactor
viernes, 25 de enero de 13
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
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
Mocks & stubs
• @TestFor
• @Mock / mockDomain
• ExpandoMetaClass
• mockFor
• Spock mocks
viernes, 25 de enero de 13
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
Controller unit test
• En ocasiones uso los “baratos” del CRUD
• Demo
viernes, 25 de enero de 13
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
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
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
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
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
Continuous testing
• Auto Test
• Guard
• Integración continua (Jenkins)
viernes, 25 de enero de 13
Análisis de código
• CodeNarc Plugin
• Test Code Coverage Plugin (Cobertura)
• Otros para Java: Findbugs, PMD, Checkstyle...
viernes, 25 de enero de 13
¿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
¿Preguntas?
viernes, 25 de enero de 13
¿Preguntas?
• www.danilat.com
viernes, 25 de enero de 13