Mitos y verdades de TDD

¿Por qué Mitos y verdades de TDD?

Escribo mi código con TDD casi desde mis inicios como desarrollador de software, y a lo largo del tiempo he visto los beneficios de hacerlo, y las consecuencias de no hacerlo. Quería compartir mi vivencia acerca de este tema.

Mitos y verdades de TDD:

“Con TDD no voy a tener más bugs”  

Falso. TDD garantiza que el código va a funcionar en la manera esperada, en los casos en los que fue pensado. No va a evitar que me olvide de considerar algún caso, o que entienda mal un requerimiento.

 

“Desarrollar con TDD es lento”

Falso. El desarrollo de software no solamente consiste en escribir el código de una funcionalidad X en un determinado momento. También es garantizar que el resto de las funcionalidades siguen andando correctamente , y es mantener y hacer crecer el código a lo largo del tiempo. Cada vez que tenemos más funcionalidades desarrolladas (y por ende más código), es exponencialmente más difícil garantizar que todo ande como debe. El hecho de tener tests unitarios y/o componentes nos ayuda a saber que rompimos algo de inmediato. Los beneficios de TDD puede que no se noten al principio del proyecto, pero a medida que va avanzando, cada vez da más valor.

 

“TDD ayuda a documentar el código”

Verdadero. Los tests unitarios nos dicen qué escenarios fueron considerados al momento de escribir el software, y cómo debe responder ante cada uno de esos escenarios. Seguramente sea la documentación más actualizada que tengamos del software, ya que los estamos manteniendo constantemente.

 

“Si hago TDD, no necesito tener un Tester en el equipo”

Falso. Los tests automatizados no reemplazan la experiencia de un tester a la hora de probar casos “raros” que no se le ocurrieron al desarrollador al momento de diseñar y escribir el software. El tester o QA debería hacer pruebas exploratorias, del tipo de “¿Qué pasa si hago esto…?

 

“Con TDD es más fácil arreglar un bug”

Verdadero. Una vez que el QA (o si somos menos afortunados, un usuario) encuentra un bug, tenemos que analizar cuál es el escenario o la combinación de datos que lo provocan, y escribir un test que reproduzca dicho escenario. Una vez que tengamos el test, podremos dedicarnos a arreglar el código productivo, teniendo la certeza de que realmente lo estamos arreglando sin romper otra cosa, gracias al resto de la bateria de tests.

 

“Con TDD el código queda más limpio”

Verdadero. Nos obligamos a escribir el mínimo código que hace pasar los tests, sin enredarnos en validaciones “por las dudas”. Además, el test nos obliga a pensar en los métodos que expondremos, qué recibirán y qué retornarán, es decir que nos ponen un poco del lado del cliente de nuestrasAPIs. Recuerden: si es difícil de escribir un test para el código, entonces tenemos que revisar el diseño.

 

“Yo tengo experiencia desarrollando, no necesito hacer TDD”

Falso. Estos personajes son los más peligrosos… Los programadores somos humanos, y como tales tenemos errores, independientemente de la experiencia previa que tengamos. Y aún suponiendo que seas un semidiós, seguramente en 6 meses vas a tener que agarrar el código de nuevo, y ahí te desafío a cambiar algo sin tener los tests que soporten el código…

 

Para cerrar, les dejo una frase que se me vino a la mente cuando estaba escribiendo este artículo: “Cualquier tonto puede escribir código que un ordenador entiende. Los buenos programadores escriben código que los humanos pueden entender.” (Martin Fowler)