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