TDD y Baby Steps

Ya saben que TDD (Test-Driven Development) es uno de mis temas favoritos. Y no sólo porque me gusta, sino porque creo que es uno de los temas a difundir para mejorar la calidad de nuestro trabajo, tanto en el código entregado como en la calidad de vida de nuestro día laboral. Soy un convencido de que el código de producción escrito SIN TDD debería estar prohibido, directamente. Y si insisto con el tema, es porque no veo que se aplique y entienda TDD, por lo menos en estos lares, Buenos Aires y Argentina. Por ejemplo, escucho por ahí:

- “TDD es más lento”, no lo veo así, es un caso de “vísteme despacio que estoy apurado”.

- “TDD no es para los programadores junior”, no, cuanto más inexperto es el programador, más va a aprender y mejorar haciendo TDD y usando el cerebro, claro ;-) TDD no produce mejores programadores, pero los hace pensar en lo que están haciendo.

- “TDD es hacer test y code coverage”, por favor, no me presenten a una persona que piense así. O que piense que TDD es aprender a hacer test unitarios, sea lo que sea que “unitario” signifique.

- “TDD es aburrido”, para mí es como un juego, cada test en verde es como superar un nivel de juego.

Una de las actividades que me nacen naturalmente cuando hago TDD, es que lo que escribo va creciendo de a poco, de a “baby steps”, de a pasos de bebé. En vez de hacer un gran salto en la implementación, si uno realmente programa con TDD va agregando poco código en cada test que se agrega. Y no se agrega código que no nazca, que no tenga una traza que lo remita a la necesidad de un test. Esto consiga que el software que vamos creando, crezca como si fuera un organismo vivo, desarrollándose de a poco. Esto trae varias consecuencias:

- Cada código agregado tiene su función específica: hacer que un test pase a verde

- No aparece código “por las dudas” o por casos de uso todavía no implementados.

- No pensamos “por adelantado”, poniendo código que todavía no necesitamos (evitamos romper YAGNI).

- No se adopta tecnología o soluciones (librerías, frameworks, base de datos, etc… ) hasta el momento en el que REALMENTE se necesitan.

Y algo menos evidente:

- El código que vamos armando es pasible de refactorización en cualquier momento

- Y aún puede haber más que refactorización, sino también cambiar algo de nuestro diseño, sin grandes “dolores”

Ahora les advierto: no se puede aplicar todo esto con TDD, si parte del código QUE ESCRIBIMOS NOSOTROS no lo hacemos con TDD. Porque entonces vamos a "sufrir" cuando lleguemos un día a necesitar refactorizar, o rediseñar, y entonces la parte del código que habíamos escrito SIN TDD nos va a pesar y nos va a complicar ese paso de refactor o de rediseño.

Me gustaría mostrarles un ejemplo, pueden ver los posts y series:

TDD Paso a Paso

Escribiendo una aplicación con TDD

Escribiendo un Intérprete en .NET

VAN en Alt.NET Hispano: Desarrollando una Aplicación con TDD

con video en Desarrollando una aplicación con TDD desde cero con código en https://github.com/ajlopez/TddOnTheRocks/tree/master/TddApp

y mis posts de TDD.

Pero cada día, en mi cuenta de GitHub, voy haciendo commits por test, así que pueden entrar a algún proyecto y ver cómo va evolucionando. Por ejemplo, hoy voy a empezar a codificar SimpleKeeper (una especie de ZooKeeper pero en Node.js). Pueden en cualquier momento entrar a ver la lista de commits e ir revisando si cumplo o no cumplo con TDD y “baby steps”.

Algo muy interesante, y relacionado con este post, es:

Kent Beck’s Four Hats

Controlling the size of your checkout is a valuable coding skill. You should be able to take small, baby steps, and check-in at any time. There are a number of benefits. If you check-in frequently the merge to source control becomes trivial. Your colleagues won’t get annoyed, because that change which they need is never far away. Most importantly you are in control of your work.

Vean ahí los cuatro sombreros de Kent Beck.

Nos leemos!

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

This entry was posted in 11699, 12081, 12114, 15035, 3463. Bookmark the permalink.

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>