Download - TDD, Una guía de supervivencia
TDD GUIA DE SUPERVIVENCIA
Un relato de horrores... by @AlfredoCasado
martes 1 de noviembre de 2011
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
martes 1 de noviembre de 2011
martes 1 de noviembre de 2011
martes 1 de noviembre de 2011
PRIMER HORROR¡Rojo significa que te pares!
martes 1 de noviembre de 2011
PRIMER HORROR
COMMIT AND...
RUN!!
martes 1 de noviembre de 2011
SEGUNDO HORROR
SUT
mock
mock
mock
mock
mock
mock
mock
mock
La obsesión unitaria
martes 1 de noviembre de 2011
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
TERCER HORRORMis test se parecen mucho...
(duplicación primer capitulo)
martes 1 de noviembre de 2011
TERCER HORRORduplicación de fixtures
En test de integración o end-to-end
martes 1 de noviembre de 2011
TERCER HORRORSolución aceptable: @Rules (JUnit 4.7+)
martes 1 de noviembre de 2011
CUARTO HORRORduplicación segundo capitulo
Mismo API debe soportar varias versiones de un esquema de base de datos
Esquema v1.0
Esquema v1.1
APIApp Cliente
martes 1 de noviembre de 2011
CUARTO HORROR¿Herencia?
martes 1 de noviembre de 2011
CUARTO HORRORExtendiendo 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
QUINTO HORRORFicheros con datos de test, ¡gran idea!
martes 1 de noviembre de 2011
QUINTO HORRORTest que no tienen given
Test data builder
martes 1 de noviembre de 2011
SEXTO HORROR
¿Donde están mis test?
martes 1 de noviembre de 2011
SEXTO HORRORCon 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
SEPTIMO HORROR
pedazo de UI, y ahora vas y lo pruebas...
martes 1 de noviembre de 2011
reloj o algo similar
OCTAVO HORROR¿No llevarás prisa?, el build tarda un ratito...
martes 1 de noviembre de 2011
un doctor, incluso el doctor de los simpson?
NOVENO HORROR¿doctor que me pasa?
usted tiene una... NullPointerException!
martes 1 de noviembre de 2011
NOVENO HORRORLos test se diseñan para fallar
martes 1 de noviembre de 2011
NOVENO HORRORLas excepciones hay que capturarlas!
martes 1 de noviembre de 2011
DECIMO HORROR¿Que probará este test?
Esto lo único que “prueba” es que no sabes hacer test
martes 1 de noviembre de 2011
DECIMO HORROR
¿No falta algo?, ¿y los assert?
martes 1 de noviembre de 2011
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