¿Qué es el desarrollo guiado por pruebas?

Usa la metodología TDD y el conjunto de pruebas proporcionado para resolver ejercicios

El desarrollo guiado por pruebas (a veces llamado desarrollo con pruebas primero o diseño guiado por pruebas) es la práctica de escribir primero las pruebas unitarias, antes de escribir una sola línea del código de la implementación.

¡En Exercism, las pruebas son los requisitos!

Todos los ejercicios de práctica en los que trabajes (esos que no te enseñan un concepto nuevo) incluyen instrucciones que describen en términos generales lo que tienes que hacer. Por diseño, estas instrucciones no tienen en cuenta los detalles de implementación específicos de cada lenguaje de programación, porque las comparten los más de 70 tracks de lenguajes de Exercism. Algunos tracks añaden detalles más específicos, pero no todos lo hacen.

Cuando empieces a trabajar en un ejercicio de práctica, lee las instrucciones con atención. Te darán una visión general de cómo abordar la implementación de una solución. Pero tendrás que leer las pruebas para entender los requisitos completos y exactos:

  • ¿El resultado tiene que ser un tipo concreto de estructura de datos?
  • ¿El resultado tiene que estar ordenado de alguna forma?
  • ¿Cómo se espera que gestiones las excepciones? Y así sucesivamente.

Has resuelto un ejercicio cuando todas las pruebas incluidas se ejecutan y pasan. En otras palabras, tu solución no es solo una interpretación de las instrucciones que «parece correcta»; tu solución es un programa que satisface las pruebas dadas. Las pruebas representan los requisitos completos del ejercicio.

¿Cómo aplica Exercism el TDD?

Ya hemos hecho el trabajo de escribir un conjunto de pruebas unitarias para ti. Tu objetivo es escribir una solución que contenga justo el código necesario para que todas esas pruebas unitarias pasen.

Ten en cuenta esto: el enfoque TDD te ayudará a llegar a la solución, pero no tienes por qué quedarte ahí. Si quieres ampliar tu solución más allá de los requisitos, adelante. Si decides trabajar con un mentor (y te animamos a hacerlo en cuanto consigas que pasen las pruebas), podrá ayudarte a refactorizar y mejorar tu implementación inicial, o incluso proponerte nuevas pruebas unitarias.

Trabajar en el editor en línea

Cuando trabajas en el editor de código del sitio web de Exercism, puedes leer las pruebas, pero no editarlas. Todas las pruebas se ejecutarán cada vez que las ejecutes, independientemente de los mecanismos de «skip» que se indiquen en el archivo de pruebas.

Cuando hay varias pruebas que fallan, el sitio web solo muestra inicialmente el resultado del primer fallo. También puedes hacer clic en otros fallos para expandirlos. A veces, el primer resultado puede no ser el más informativo.

No te desanimes si fallan muchas pruebas. Céntrate en hacer que pasen una a una.

Trabajar en local

Muchos tracks marcan algunas pruebas como «skip» en sus archivos de pruebas. Al principio, solo la primera prueba está «activa» y el resto están inactivas (cómo ocurre esto varía según el track). Cuando ejecutas el conjunto de pruebas en tu entorno, solo se ejecuta la primera. Hacemos esto para animarte a seguir este flujo de trabajo:

  1. Antes de añadir código nuevo, ejecuta el conjunto de pruebas: deberías ver una prueba que falla.
  2. Añade justo el código necesario para que la prueba pase.
  3. Ejecuta el conjunto de pruebas.
  4. Si la prueba sigue fallando, repite el paso 2.
  5. Cuando la prueba pase, refactoriza tu código como quieras, asegurándote de que todas las pruebas activas siguen pasando. La refactorización puede incluir:
    • eliminar el código duplicado,
    • dividir las funciones largas en otras más pequeñas,
    • añadir comentarios, etc.
  6. Quita el «skip» de la siguiente prueba y repite desde el paso 1.

Repite estos pasos hasta que hayas quitado el «skip» de todas las pruebas. Cuando todas las pruebas pasen, ¡enhorabuena, has resuelto el ejercicio!

La forma exacta de quitar el «skip» (o activar) las pruebas depende del track. En algunos tracks, puede ser comentar o eliminar una anotación. En algunos tracks, puede ser cambiar un atributo de true a false. Tómate tu tiempo para leer la documentación de tu track; ahí se explican estos detalles.

En los tracks que no marcan las pruebas con «skip», aplicar este flujo de trabajo puede ser tan sencillo como comentar las pruebas e ir descomentándolas una a una.

Motivos para usar el desarrollo guiado por pruebas

Aunque pueda parecer que «empezamos la casa por el tejado», hay varias buenas razones para escribir las pruebas unitarias antes que el código de la implementación.

  1. Diseño. Te obliga a pensar primero en la interfaz de tu programa (cómo expone su funcionalidad al mundo), en lugar de lanzarte directamente a cómo vas a implementar el código. Tener una interfaz bien diseñada (¡y fácil de probar!) suele ser más importante que tener una implementación eficiente.

  2. Disciplina. Escribir pruebas suele verse como una tarea pesada o algo que se deja para el final; escribir las pruebas primero garantiza que, al final, habrás escrito suficientes pruebas unitarias para cubrir la mayor parte de la funcionalidad de tu código, o toda ella, en lugar de quizá no llegar a hacerlo nunca.

  3. Menos trabajo. Si aplicas un ciclo ajustado de escribir una prueba, luego escribir el código que la implemente y después la siguiente prueba, tu código acaba creciendo de forma orgánica. Esto a menudo (aunque no siempre) se traduce en menos esfuerzo desperdiciado: acabas escribiendo todo el código que necesitas y nada del que no necesitas.

Para seguir leyendo