El desarrollo guiado por tests (a veces llamado desarrollo con los tests primero o diseño guiado por tests) es la práctica de escribir primero los tests unitarios, antes de escribir una sola línea de código de implementación.
¡En Exercism, los tests son los requisitos!
Todos los ejercicios de práctica en los que trabajes (esos que no te enseñan un concepto nuevo) tendrán instrucciones que describen en términos generales lo que necesitas hacer.
Deliberadamente, estas instrucciones no toman 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 de lenguajes te añadirán detalles más específicos, pero no todos lo hacen.
Cuando empiezas 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 los tests para entender los requisitos completos y exactos:
- ¿El resultado debe ser un tipo particular de estructura de datos?
- ¿El resultado debe estar ordenado de alguna manera?
- ¿Cómo se espera que manejes las excepciones? Y así sucesivamente.
Has resuelto un ejercicio cuando todos los tests proporcionados se ejecutan y pasan.
En otras palabras, tu solución no es solo una interpretación de las instrucciones que «se ve bien»; tu solución es un programa que satisface los tests dados.
Los tests representan los requisitos completos del ejercicio.
¿Cómo aplica Exercism el TDD?
Ya nos encargamos de escribir un conjunto de tests unitarios para ti.
Tu objetivo es escribir una solución que contenga justo el código necesario para que todos esos tests unitarios pasen.
Ten esto presente: el enfoque TDD te ayudará a llegar a la solución, pero no tienes que detenerte ahí.
Si quieres extender tu solución más allá de los requisitos, eres libre de hacerlo.
Si decides trabajar con un mentor (y te animamos a hacerlo una vez que tus tests pasen), podrá ayudarte a refactorizar y perfeccionar tu implementación inicial, o incluso proponerte nuevos tests unitarios.
Cómo trabajar en el editor en línea
Cuando trabajas en el editor de código del sitio web de Exercism, puedes leer los tests, pero no puedes editarlos.
Todos los tests se ejecutarán cada vez que los ejecutes, sin importar los mecanismos para omitir tests que se indiquen en el archivo de tests.
Cuando hay varios tests que fallan, el sitio web al principio solo muestra los resultados de la primera falla.
¡También puedes hacer clic en otras fallas para expandirlas!
A veces el primer resultado puede no ser el más informativo.
No te desanimes si hay una gran cantidad de tests que fallan.
Concéntrate en hacerlos pasar uno por uno.
Muchos tracks usan tests «omitidos» en sus archivos de tests.
Al principio, solo el primer test está «activo» y el resto están inactivos (cómo ocurre esto varía según el track).
Cuando ejecutas el conjunto de tests en tu entorno, solo se ejecuta el primer test.
Hacemos esto para animarte a seguir este flujo de trabajo:
- Antes de agregar código nuevo, ejecuta el conjunto de tests: deberías ver un test que falla.
- Agrega justo el código necesario para que el test pase.
- Ejecuta el conjunto de tests.
- Si el test aún falla, repite el paso 2.
- Cuando el test pase, refactoriza tu código como quieras, asegurándote de que todos los tests activos sigan pasando.
La refactorización podría incluir:
- eliminar el código duplicado,
- dividir funciones largas en funciones más pequeñas,
- agregar comentarios, etc.
- «Deja de omitir» el siguiente test y repite desde el paso 1.
Repite estos pasos hasta que hayas dejado de omitir todos los tests.
Cuando todos los tests pasen, ¡felicidades, has resuelto el ejercicio!
La forma exacta de «dejar de omitir» los tests (o de activarlos) depende del track.
En algunos tracks, puede ser comentar o eliminar una anotación.
En otros, puede ser cambiar un atributo de true a false.
Tómate el tiempo de leer la documentación de tu track; allí se explican estos detalles.
En los tracks que no omiten los tests, aplicar este flujo de trabajo puede ser tan simple como comentar los tests y descomentarlos uno por uno.
Razones para aplicar el desarrollo guiado por tests
Aunque pueda parecer «poner el carro delante del caballo», hay varias buenas razones por las que querrías escribir tests unitarios antes de escribir el código de implementación.
-
Diseño.
Te obliga a pensar primero en la interfaz de tu programa (cómo expone su funcionalidad al mundo), en lugar de lanzarte de inmediato a cómo vas a implementar el código.
Tener una interfaz bien diseñada (¡y que se pueda testear!) suele ser más importante que tener una implementación eficiente.
-
Disciplina.
Escribir tests suele verse como una tarea tediosa o como algo que se deja para después; escribir los tests primero garantiza que al final del día habrás escrito suficientes tests unitarios para cubrir la mayor parte de la funcionalidad de tu código, o toda ella (en lugar de quizás no llegar a hacerlo nunca).
-
Menos trabajo.
Si aplicas un ciclo ajustado de escribir un test, luego escribir el código que implementa ese test y después el siguiente test, tu código termina creciendo de forma orgánica.
Esto a menudo (aunque no siempre) lleva a desperdiciar menos esfuerzo; terminas escribiendo todo el código que necesitas y nada del que no necesitas.
Lecturas adicionales
