No uses TDD para escribir pruebas que pasan el test

Si tu proceso es orientado por TDD y dedicas tu esfuerzo en escribir código que pasa el test, entonces lo que estás haciendo es duplicar tu código y por ende perder tu tiempo.

TDD tiene algunos principios que parecieran ser rígidos y no tener una razón de ser, pero uno de ellos indica que debes escribir códigos de pruebas para fallos, hasta que las pruebas fallen (que no tengan éxito las pruebas implica que el código pasará el test), luego de que las pruebas fallen, debes generar el código para producción que indudablemente pasará cualquier test con éxito (por que ya habrás saltado las fallas).

He visto en la red a muchos "Evangelistas TDD" que dicen que no hay nada que impida crear código para demostrar que pasa el test y que ellos prefieren hacer eso en algún porcentaje por garantías. Esto me resulta tan incomprensible en TDD, como no hacer test de tu código considerando las alternativas de fallo (en procesos no TDD), por considerar que construir el "camino feliz" es suficiente.

Las tres reglas del TDD (http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd)

#2 "You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures“

Significa, no escribir nada más que pruebas unitarias para fallos. Una compilación fallida es un fallo.

 

Las otras dos reglas básicamente parecieran decir lo mismo:

#1 You are not allowed to write any production code unless it is to make a failing unit test pass.

Significa, no adicionar líneas extra de código en producción a menos que sea para que pase una prueba unitaria fallida.

#3 You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

Significa, no escribir más código en producción que aquel necesario para pasar las pruebas unitarias fallidas

Advertisements