Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a TDD talk
Similar a TDD talk (20)
Último
Último (20)
TDD talk
- 1. Welcome https://www.linkedin.com/in/alberto-gonzalez-lizan https://twitter.com/agonzalezlizan Alberto González Lizán agonzalez@addentra.net La tecnología, una de mis pasiones Formación Ingeniero informático (2004-2009) Master en Dirección de Proyectos Informáticos (2018-2019)
- 2. CTO de Addentra Internet SL Welcome agonzalez@addentra.net ¿Qué es Addentra? Empresa con más de 10 años de trayectoria dedicada al desarrollo de SW (Guadalajara / Madrid). Producto propio Hemos desarrollado uno de los SW líder en el panorama de la gestión de clínicas dentales. Actualmente desarrollando un nuevo producto muy potente. Construimos SW de calidad. … Más al final.
- 3. Test Driven Development (TDD) Charla técnica a la par que entretenida Historia del TDD Trabajaremos con un ejemplo básico Mis errores y experiencias Guiños a los gerentes y a detractores Integración con SCRUM Nuevos desarrolladores en TDD agonzalez@addentra.net Y voy a hablar…. ¡Para contársela a aquellos gerentes que todavía no se lo crean!
- 4. Desarrollo guiado por pruebas ¿TDD? agonzalez@addentra.net
- 5. agonzalez@addentra.net ¿Quién lo inventó? Kent Beck https://twitter.com/KentBeck https://www.linkedin.com/in/kentbeck/ https://www.kentbeck.com/ Creador de las metodologías de programación extrema Uno de los 17 firmantes del manifiesto ágil Test Driven Development. By Example
- 6. agonzalez@addentra.net TDD ¿para qué? Más robusto Más seguro Más fácil de mantener Mayor rapidez en el desarrollo
- 7. agonzalez@addentra.net TDD ¿para qué? Aumentamos la CALIDAD del SW ¿Quién no quiere sentirse productivo? Más satisfechos con nuestro trabajo Aumenta nuestra motivación Aumenta nuestra productividad
- 8. agonzalez@addentra.net TDD, ¿aporta algo más? Documentación Clean Code Escalabilidad de tu equipo Menor número de bugs Satisfacción de los clientes
- 9. agonzalez@addentra.net ¿Cómo funciona? Requisito/funcionalidad no implementado/a
- 10. agonzalez@addentra.net Un poco de teoría… Clase/Componente SUT Spec de la Clase/Componente Suite de test (describe) Suite de test (describe) Test (it) Test (it) … Test (it) Test (it) … Sintaxis: FW Jasmine expect expect
- 11. agonzalez@addentra.net ¿Y las dependencias? Una de las grandes barreras del TDD ¡Los objetos instanciados en una clase no son testeables! “Dobles de test”
- 12. agonzalez@addentra.net Dobles de test Martin Fowler “Test doubles is a generic term for any kind of pretend object used in place of a real object for testing purposes” Mock Stub Fake
- 13. agonzalez@addentra.net Veamos un ejemplo… Aplicación web Angular v8 Jasmine v3.4.0 https://github.com/gonzalezlizan/tddtalk
- 14. agonzalez@addentra.net Veamos un ejemplo… Componente interfaz gráfica Servicio encargado de los cálculos Recoger los datos de la interfaz Conexión con servicio y pintar el resultado Se encarga de los cálculos matemáticos
- 16. agonzalez@addentra.net ¿Cómo medir los tests? Aspecto de referencia para verificar la calidad de nuestros tests Cerca del 75% ¡Cuidado! El coverage verifica que secciones de código ejecuta el test, pero eso no quiere decir que sean correctos Code Coverage Combinarlo con Pair Programming o Code Reviews
- 18. agonzalez@addentra.net Un bug con TDD ¿Quién reparando un bug ha generado otro? ¿Quién ha reparado el mismo bug en varias ocasiones? Reproducimos el bug en un test Retocamos el código para que el test sea satisfactorio Ejecutar resto de tests y verificamos que no hemos roto nada
- 20. agonzalez@addentra.net TDD… ¿es suficiente? ¡NO! TDD garantiza que el código va a funcionar en la manera esperada, en los casos en los que fue pensado No va a evitar que me olvide de considerar algún caso o que entienda mal un requisito TDD + e2e
- 22. agonzalez@addentra.net Developers con TDD Los inicios no son fáciles Más significativa a mayor experiencia en el desarrollo de SW sin TDD
- 23. agonzalez@addentra.net Developers con TDD Confianza Mayor calidad en el código desarrollado Factor de motivación intrínseco
- 24. agonzalez@addentra.net Developers con TDD Refactorización “Si algo funciona, no lo toques” “Si algo se puede mejorar, hazlo” Código óptimo, mantenible y claro Código reutilizable Menos bugs
- 25. agonzalez@addentra.net Developers con TDD Sin depuración No es necesario depurar Ahorro de tiempo y aumento de productividad
- 26. agonzalez@addentra.net Managers con TDD Apoyo de la dirección Dudas en el proceso de implantación
- 28. agonzalez@addentra.net Managers con TDD Potencia tu equipo Motivación intrínseca Facilita integración de Juniors Mayor confianza en los resultados GTD (Getting Things Done)
- 29. agonzalez@addentra.net Managers con TDD Satisfacción de clientes Tests están pensados desde el punto de vista del cliente Menos bugs
- 30. agonzalez@addentra.net Reduce el Time To Market Nos permite garantizar que una versión sea susceptible de entregar al cliente de una manera mucho más rápida Managers con TDD
- 31. agonzalez@addentra.net Integración TDD+SCRUM Integración directa Client/Product Owner comenta necesidad Historias de usuario con requisitos de DONE For sprint (historias de usuario seleccionadas) 1. For historia de usuario 1. For criterios de aceptación a. Red Test/s b. Code c. Green Test/s d. Refactor e. All Tests
- 32. agonzalez@addentra.net Errores con TDD Code before Test Común en los inicios con TDD Muy peligroso Solución Experiencia
- 33. agonzalez@addentra.net Errores con TDD Duplicidad de tests Mal planteamiento Solución Experiencia
- 34. agonzalez@addentra.net Errores con TDD Baja cobertura No testear por completo el comportamiento Solución Herramienta de coverage (> 75%)
- 35. agonzalez@addentra.net Errores con TDD Tests innecesarios Testing de funciones privadas o comportamientos innecesarios Solución Experiencia
- 36. agonzalez@addentra.net Errores con TDD Falsa sensación de seguridad Los tests no significa que no haya errores en el código, sino que puede ser que no haya un test que cubra el error Solución e2e
- 37. agonzalez@addentra.net Errores con TDD Menospreciar el rendimiento Ejecución de todos los tests muy costosa en tiempo. Solución Optimización de los tests, soluciones de simulado de navegador para aplicaciones web
- 38. agonzalez@addentra.net ¿Y sin TDD? “Una vez que trabajas con TDD pues ….” • Construcción de prototipos (proyectos con requisitos cambiantes diariamente) • Proyectos con deadline muy fuerte y equipo sin experiencia en TDD Efecto rebote
- 39. agonzalez@addentra.net Perfiles que comienzan con TDD Junior: buena aceptación (3-6 meses) Senior que se adaptan: buena aceptación (2-4 meses) Senior que no se adaptan
- 40. agonzalez@addentra.net Conclusiones Gerente Incremento de la productividad del equipo Ahorro de costes Desarrollador Minimización del retrabajo Motivación intrínseca. Cliente Productos con una menor cantidad de errores Satisfacción mayor
- 41. agonzalez@addentra.net ¿Y esto lo hacéis en Addentra? ¡Sí! TDD Últimas tecnologías IA Agile Producto propio ¡Jornada continua todo el año! ¿Quieres conocernos?
Notas del editor
- Construimos SW de calidad por la experiencia de muchos años de desarrollo
- Clean code por la refactorización
- SUT = Sujeto bajo test
- Doble de test: Verificamos que los parámetros con los que se invoca o que la asignación se realiza con el valor/es correcto/s
- Fowler: también es firmante del manifiesto ágil de 2001 Mock: Suplanta al objeto real del cual depende Valida comportamiento Guardan las acciones que se hacen sobre ellos Necesario configurar qué comportamiento esperas cuando alguien llame a alguno de sus métodos Stub: Objeto en el que configuras que cuando llames a un método devuelva un valor determinado. Ej: Objeto que para un método de suma independientemente de los valores que le pases devuelva 5 Fake Es un objeto que implementado completamente y que funciona, como un objeto normal sin ser simulado, pero se diferencia en que está falseando algo para hacer alguna cosa más fácil de probar. Base de datos en memorio, en lugar de acceder a una de producción
- Exponer estructura. Explicar inyección en AppComponent del servicio (revisar mock). Explicar testing y code en AppComponent Explicar testing y code en el servicio. // Bad practise. I don't recommend use class code on tests (+) Revisar integración de la funcionalidad de PI
- En muchas ofertas se usa como referencia para reflejar la “calidad” de los tests unitarios
- En el develop/servicio CON FIT
- Con los test e2e logramos testear el flujo entero. Cuando se realizan pruebas unitarias, los componentes de una aplicación se prueban de manera aislada, sin embargo, esto tiene la desventaja de no ser capaz de verificar la integridad de la información mientras es pasada de un componente de la aplicación a otro. Usando pruebas E2E resolvemos este problema interactuando con la aplicación como un usuario regular lo haría, y, por lo tanto, utilizando cada parte de la aplicación y evaluando las respuestas para el comportamiento esperado. El FW empleado es protractor.
- Develop: npm run e2e
- Principio es bastante frustrante pues parece que los tiempos se extienden en exceso y es complejo adaptarse Como anécdota curiosa hace unos meses un junior de nuestra empresa se disponía a realizar unos cambios en una plataforma que no está desarrollada con TDD, y su pregunta era ¿Cómo se hace sin TDD? No pude evitar sentir que estábamos haciendo un excelente trabajo con nuestra cantera.
- Confianza. Mayor calidad en el código desarrollado Motivación intrínseca!
- Apoyo de la dirección. CLAVE Dudas. Los tiempos se dilatan. Se tiende a evaluar TDD en gente que no tiene experiencia con la metodología y por lo tanto los tiempos se dilantan, pero no por TDD sino por el proceso de aprendizaje del desarrollador
- Siempre que he podido hablar sobre desarrollo con algunos gerentes parece que TDD sea un “enemigo”, pues parece que existirá un sobrecoste en la desarrollo. Sin embargo, lo cierto es que el coste finalmente es mucho mayor pues se invierte en los infinitos mantenimientos y en las costosas puestas en producción. A partir de la experiencia que hemos tenido con dos de nuestros productos en nuestra compañía se pueden extraer los siguientes datos. Y ojo, siendo pesimista partiendo de la base de que con TDD se tardará algo más en el desarrollo, cosa que sinceramente no termino de tener claro.10 En esta tabla podemos ver que una vez está desarrollado, los tiempos empiezan a dispararse, pues encima los bugs en producción pueden generar un sobrecoste exponencial, a parte de el impacto negativo en nuestros clientes.
- Motivación intrínseca al tratarse de resultados de calidad Integración de juniors al poder confiar en ellos por no haber daños colaterales GTD se centran en hacer una cosa a la vez para mejorar la productividad. Getting Things Done es un método de productividad desarrollado por David Allen que ha sido aceptado mundialmente como una de las metodologías más eficientes de organización personal. Como se puede leer en la Wikipedia, GTD se basa en el principio de que una persona necesita liberar su mente de las tareas pendientes guardándolas en un lugar específico, de forma que no sea necesario recordar lo que hay que hacer y se puede concentrar en realizar las tareas. Esta es una de las bases de TDD, primero específicas todas las pruebas y posteriormente vas implementando cada funcionalidad una a una.
- Muchas veces tendemos a engañarnos pensando en que vamos a pensar como hacerlo tirando código, y finalmente terminamos tirando todo el código y dejando los tests para el final. Esto a parte de ser menos productivo es muy peligroso pues puede resultar que los tests no testean de forma correcta el funcionamiento deseado.
- Una vez que trabajas con TDD pues …. CASO DE PEPE. Tenía miedo e inseguridad al programar sin TDD. Al final no usarlo se salva de igual manera con esfuerzo humano ¡¡¡¡¡PEPE EN RADIOFÍSICA!!!!!! OJO! Donde no aplicarlo es por dar ejemplos, que yo lo usaría de igual manera. Interfaz y BDD Proyectos con deadline….. Se puede producir el efecto rebote y que la gente odie el TDD
- Por nuestra experiencia en la integración de perfiles a TDD….