Hoy vamos a conocer una técnica llamada TDD (del inglés test-driven development, desarrollo guiado por pruebas) que nos propone una manera diferente de encarar un problema de programación: empezando por las pruebas.

¿Y para qué querríamos hacer esto? Según Kent Beck, uno de los creadores de la técnica, para reducir el miedo que tenemos al programar. Específicamente, el miedo entendido como “no tengo la menor idea de cómo encarar este problema ni de cuanto me va a llevar”. Otras razones, un poco más técnicas: nos ayuda a producir código con un alto nivel de cobertura (porcentaje de código que prueban los tests), nos hace mantener el diseño simple y contribuye a no generar deuda técnica.

La técnica se puede contar en tres simples paso, que muchas veces se resumen en Red - Green - Refactor:

  1. Agregá un pequeño test automatizado que te acerque a la funcionalidad que querés desarrollar. No tiene que cubrir todos los casos ni ser complejo: solo buscamos que nos acerque un pasito a la solución. Es importante que esta prueba falle, porque eso da cuenta de que nuestro sistema aún no resuelve ese problema.
  2. Escribí el mínimo código necesario para que esa prueba pase. No importa si ese “mínimo código” parece ridículo y contradice todo lo que te enseñaron hasta ahora, ya tendremos tiempo de mejorarlo.
  3. Refactorizá tu código para eliminar la duplicación que hayas introducido en el paso anterior.

Inmediatamente después de leer esto surgen preguntas del estilo:

  • ¿Cómo es un pequeño test?
  • ¿A qué llamamos “mínimo código”?
  • ¿Hasta dónde refactorizar?

El anticipo es que esas preguntas no tienen respuesta absoluto, sino que dependen de muchos factores: el equipo, el tiempo que tengamos, la tecnología que estemos usando, la dificultad del problema que nos ocupe, las ganas que tengamos ese día, etc.

Pero algo es seguro, no podemos aprender una técnica solamente leyendo de un blog ¡tenemos que ponerla en práctica! Allá vamos nomás.

¡Manos a la obra!

Para esta práctica vas a necesitar: