TDD, Una guía de supervivencia
2 recomendaciones901 vistas
Este documento describe 10 horrores comunes que los desarrolladores enfrentan al implementar pruebas unitarias con TDD por primera vez. Incluye problemas como tests que fallan al compilar, excesiva dependencia de mocks, duplicación de código de prueba y dificultades en la organización y localización de los tests. El autor concluye que TDD es un proceso de mejora continua y que aunque queda mucho por aprender, ya se ha avanzado significativamente desde los inicios.
TDD, Una guía de supervivencia
- 1. TDD GUIA DE SUPERVIVENCIA Un relato de horrores... by @AlfredoCasado martes 1 de noviembre de 2011
- 2. Un poco de contexto... Desarrollo de producto Media de 4 desarrolladores muy motivados Sin experiencia con TDD JAVA (aka the new cobol) Muchas lineas, más de 200k (test incluidos) martes 1 de noviembre de 2011
- 3. martes 1 de noviembre de 2011
- 4. martes 1 de noviembre de 2011
- 5. martes 1 de noviembre de 2011
- 6. PRIMER HORROR ¡Rojo significa que te pares! martes 1 de noviembre de 2011
- 7. PRIMER HORROR COMMIT AND... RUN!! martes 1 de noviembre de 2011
- 8. SEGUNDO HORROR La obsesión unitaria mock mock mock mock SUT mock mock mock mock martes 1 de noviembre de 2011
- 9. SEGUNDO HORROR Sólo es un problema... cuando no sabes programar Mucho acoplamiento => demasiados mocks ¿ley de demeter?, ¿de quien? => mocks que devuelven mocks que devuelven mocks... Depender de abstracciones al extremo => una interfaz, una implementación No escuchar a tus test => si el test se complica demasiado... revisa tu diseño. Escribir estos test despues del código => SUICIDIO. martes 1 de noviembre de 2011
- 10. TERCER HORROR Mis test se parecen mucho... (duplicación primer capitulo) martes 1 de noviembre de 2011
- 11. TERCER HORROR duplicación de fixtures En test de integración o end-to-end martes 1 de noviembre de 2011
- 12. TERCER HORROR Solución aceptable: @Rules (JUnit 4.7+) martes 1 de noviembre de 2011
- 13. CUARTO HORROR duplicación segundo capitulo Mismo API debe soportar varias versiones de un esquema de base de datos Esquema v1.0 App API Cliente Esquema v1.1 martes 1 de noviembre de 2011
- 14. CUARTO HORROR ¿Herencia? martes 1 de noviembre de 2011
- 15. CUARTO HORROR Extendiendo JUnit con nuestro propio runner El test se ejecutará dos veces, una para cada versión de base de datos. martes 1 de noviembre de 2011
- 16. QUINTO HORROR Ficheros con datos de test, ¡gran idea! martes 1 de noviembre de 2011
- 17. QUINTO HORROR Test que no tienen given Test data builder martes 1 de noviembre de 2011
- 18. SEXTO HORROR ¿Donde están mis test? martes 1 de noviembre de 2011
- 19. SEXTO HORROR Con los test unitarios es fácil ¿Los de integración donde van?, ¿y los funcionales? ¿organizar por sprints?, ¿por funcionalidad?, ¿test que resuelven bugs aparte?, ¿en el mismo proyecto?, ¿en un proyecto para test? martes 1 de noviembre de 2011
- 20. SEPTIMO HORROR pedazo de UI, y ahora vas y lo pruebas... martes 1 de noviembre de 2011
- 21. OCTAVO HORROR ¿No llevarás prisa?, el build tarda un ratito... reloj o algo similar martes 1 de noviembre de 2011
- 22. NOVENO HORROR ¿doctor que me pasa? un doctor, incluso el doctor de los simpson? usted tiene una... NullPointerException! martes 1 de noviembre de 2011
- 23. NOVENO HORROR Los test se diseñan para fallar martes 1 de noviembre de 2011
- 24. NOVENO HORROR Las excepciones hay que capturarlas! martes 1 de noviembre de 2011
- 25. DECIMO HORROR ¿Que probará este test? Esto lo único que “prueba” es que no sabes hacer test martes 1 de noviembre de 2011
- 26. DECIMO HORROR ¿No falta algo?, ¿y los assert? martes 1 de noviembre de 2011
- 27. Terminando: TDD no es un fin, es un camino. No se si hemos avanzado mucho o poco, pero si se que estamos muy lejos de donde empezamos y más lejos aún de donde terminaremos llegando. La mejora continua no acaba con las “retrospectivas”, empieza con las retrospectivas y acaba con las manos en el teclado. martes 1 de noviembre de 2011