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

2 thoughts on “No uses TDD para escribir pruebas que pasan el test

    • Se que estás en el aprendizaje de este método, de hecho yo y todos los que conozco, en alguna medida estamos en el mismo proceso de aprendizaje.
      Mi enfoque es el de confrontar a desarrolladores y autores de textos que enseñan TDD para desarrollar código para poner a prueba el “Happy Path”, luego para poner a prueba funciones que típicamente no fallarían. De modo que hasta aquí, se codificó en ambiente de UnitTest para probar funciones que cumplan con los requisitos satisfactoriamente, para luego desarrollar en ambiente de Producción esas mismas funciones. Es decir, se hizo dos veces lo mismo.

      Entonces, el enfoque TDD debe ser diferente y crear antes que nada los escenarios que podrían hacer fallar una funcionalidad en producción. Luego codificarías el testing para evitar esos fallos en el testing unitario, pero en el código de producción escribirás lo correspondiente a la funcionalidad, sabiendo como evitar los fallos, según las pruebas unitarias que hiciste antes.
      De modo tal que el enfoque viene a poner un límite a cuanto código escribes en un lado y otro (ambiente de UnitTest / ambiente de Producción) y a evitar que codifiques por duplicado. En tu ambiente de Unit Test, solo tendrás pruebas para modos de fallos y en producción solo código de funcionalidades que cumplen con los requisitos y además, con la lógica suficiente para evitar el fallo, de acuerdo al testing que hiciste en tu ambiente de Unit Test .

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s