TDD como Compilador

Veamos hoy un tema que pone en perspectiva ¿para qué sirve TDD? O por lo menos, trata de responder en gran parte esa pregunta.

Todos conocemos lo que es programar en Java o en .NET. Escribimos el programa, posiblemente usando una IDE (Eclipse, Visual Studio.NET), y llegado el momento, compilamos. Los lenguajes .NET (VB.NET, C#, otros) y Java, son lenguajes tipados. El compilador nos dice cuándo nos equivocamos, ANTES de ejecutar nuestro programa. Por ejemplo, nos dice que nos equivocamos en el nombre de un método, o que escribimos mal el nombre de una clase, o que está mal el tipo del parámetro que tenemos que pasar a una función.

Eso ha sido útil por décadas. Y entonces, es fácil confundir esa solución (detectar en compilación errores), con el problema inicial (que nuestra aplicación funcione como esperamos).

Cuando pasamos a lenguajes dinámicos, como Ruby o Python o JavaScript, algunos se resienten: hey! No tenemos compilador! No podemos asegurarnos que lo que escribimos esté bien. Sólo nos damos cuenta si lo ejecutamos. Esto parece inclinar la balanza de nuestras preferencias a los lenguajes tipados con compilación.

Pero no es así. Todos los compiladores del mundo NO PUEDEN ASEGURARNOS que lo que escribimos esté bien. No pueden asegurarnos, al compilar, QUE NUESTRO SOFTWARE HAGA LO QUE ESPERAMOS QUE HAGA.

Veamos un ejemplo en concreto. Si tenemos un método llamado “incrementar” que recibe un entero, un compilador de Java o de .NET nos va a avisar sin lo llamamos con un nombre incorrecto, o si le estamos pasando un valor real o texto en lugar de un entero. Y eso es útil. PERO NO NOS AVISA NADA sobre si el método “incrementar” cumple con lo que esperamos de él. Bien podríamos tener en ese método código que en vez de incrementar una variable interna se dedica a formatear el disco C: o a borrar todo lo que tengamos en /usr/bin. EL COMPILADOR NO NOS SIRVE para afirmar que el método hace lo que esperamos que haga.

En cambio, TDD, al escribir los tests de lo que esperamos de nuestro método “incrementar” NOS AVISA cuándo las expectativas que tenemos no se cumplen. Entonces, no hay mucha diferencia entre escribir Ruby sin compilar y sin TDD y escribir C# sin compilar y sin TDD: de las dos formas, no sabemos si lo que escribimos HACE LO QUE ESPERAMOS QUE HAGA.

Es por todo eso que veo a TDD como la próxima generación de compiladores: es lo que nos asegura que lo que escribimos esté bien, NO EN SINTAXIS, sino en lo que podemos nombrar como SEMANTICA: lo que escribimos cumple con la conducta esperada.

Accesorio: por eso no tomo tanto en cuenta a los que critican a Ruby, Python o JavaScript por no ser tipados y no poder detectar errores en “compilación”. Si escribimos siguiendo TDD, no importa tanto el lenguaje que usemos: cada línea de código que agregamos está respaldada por un test, y cada test es una condición que cumplir. Cuando TDD nos avise que un test está en rojo, es como cuando el compilador nos avisa “el método inkrementar no existe”. Es más: yo diría que nos das avisos más importantes que lo que nos da cualquier compilador.

Escribir código de producción sin TDD, es como escribir un programa ejecutable, usando un editor hexadecimal sobre el archivo compilado: nada nos asegura que lo que estamos haciendo esté bien. Si quieren escribir código de producción sin TDD, bien, tengo unos folletos para jugar ruleta rusa, si les interesa ;-)

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

This entry was posted in 10549, 11699, 12081. Bookmark the permalink.

2 Responses to TDD como Compilador

  1. Adrian says:

    Buenas tardes Angel, te comento que sigo tus publicaciones, y me intereso el tema de test TDD, sin embargo por estupido que parezca(creo que el seso no me da), todavia no logro entender de que especificamente se trata, porque hasta quise seguir uno de tus paso a paso, y no supe por donde empesar, y cada dia me haces preocupar mas con tus publicaciones, ahora, por lo que lei, hacer un test TDD significa, hacer un programa sencillo que se comunique con partes especificas de tu sistema, mandandole datos, para monitorear las salidas de este? es eso hacer un test TDD? te agradeceria mucho si pudieras quitarme esta duda, y aclararme el panorama en general, muchas gracias

  2. lopez says:

    Hola Adrian!

    Bueno, es un poco dificil resumir el tema de TDD. Pero podrias ver el ciclo en

    http://aprendiendotdd.wordpress.com/2013/02/04/esquema-algoritmo-artefactos-tdd/

    y un ejemplo paso a paso en

    http://www.youtube.com/watch?v=oLacIAxiUJ8

    Es decir, primero se escribe el test, luego se escribe codigo para que al menos compile (en los lenguajes con compilador), el test esta en rojo, luego se escribe el codigo para que el test pase a verde, el menor codigo posible. Y luego refactor.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>