Test driven development: advantages and common errors.
Why is important to use TDD?
What kind of things TDD give us?
Which are common errors using TDD?
With or without TDD?
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!
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
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
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
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
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
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
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
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?
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….