Olas Septiembre 2012 / Sopelana

Hacía años que no dedicaba algo de tiempo al bodyboard, por suerte, he tenido unos días libres y me ha cuadrado algún bañito... Divertido!!!

Resumen Clean Coders capitulo 6: TDD Parte 1

Continuamos con las acciones de mejora / compartiendo videos cleancoders. En esta ocasión toca el resumen del Capitulo 6 Parte 1

Clean Code, Episode 6 - TDD - Part 1

• Reglas TDD
• No escribir código de produccion excepto para hacer pasar un test que esta fallando
• Escribir solo lo suficiente de un test como para demostrar el fallo
• Escribir solo lo suficiente del código de produccion como para pasar el test
• Pasos TDD
• Red
• Green
• Refactor
• Miedo y Descomposición del código (Code Rot)
• El código y el diseño de un sistema suele irse deteriorando si no lo limpiamos de forma continua.
• Esto hace que el sistema sea rigido, fragil y dificil de cambiar y que las estimaciones cada vez sea más imprecisas y dificiles de hacer.
• No lo limpiamos, pq tenemos miedo (de romperlo)
• Un esfuerzo de limpieza que no sea constante no tiene sentido (normalmente cuesta mucho más y si no tenemos como validar que todo sigue funcionando, suele terminar en desastre).
• Eliminando el miedo a cambiar el código
• Gran cobertura de tests
• Que se ejecutan en muy poco tiempo
• Que se ejecutan con solo pulsar un boton o escribir un comando
• Con una buena cobertura de tests, se puede llegar a un estado en el que no se tiene miedo a que si pasan los tests, simplemente se libera la versión.
• Ventajas de disponer de una buena cobertura de tests
• No hay miedo para cambiar el código
• No hay miedo a limpiar el código
• No hay miedo a liberar una versión
• Número de bugs muy bajo

• Usando TDD en su experiencia
• El proyecto se desarrolla más rápido
• Nos ahorran tiempo
• Se desarrolla con mucha mas fiabilidad
• Muchos menos errores
• y se dedica menos tiempo a depurar
• Y la estrcutura resultante es mejor

• Las tres reglas del desarrollo TDD
• Es una disciplina y tiene una serie de reglas
• Las tres reglas
• No se puede escribir código de producción excepto para pasar un test que está fallando
• Escribe solo lo suficiente de un test para demostrar el fallo (no compilar es un fallo)
• Escribe solo lo suficiente del código en producción como para pasar el test fallando
• El ciclo debe ser de unos pocos segundos... algo de test, algo de código, algo de test, algo de código, …
• Con TDD, siguiendo estas reglas se obtiene:
• Tiempo de depuración reducido por un factor de 10
• Documentación (actualizada y funcional) con ejemplos
• El código está mucho más desacoplado dado que tiene que ser testeable, es decir un sistema mucho más flexible
• No tenemos miedo a cambiar el código
• No tenemos miedo a limpiar el código
• Es decir, el TDD, evita que el código se vaya corrompiendo