Indice de contenidos
Las tres leyes del TDD
Robert C. Martin («Uncle Bob») ofrece una serie de reglas concisas para trabajar con TDD:
- No escribas un código a menos que escribas una prueba unitaria que falle.
- No escribas más de una prueba unitaria suficiente para fallar (también un código que no compila se considera como fallo).
- No escribas más código de producción de lo necesario para pasar una prueba unitaria.
¿Por qué se debe de pensar y utilizar TDD en Scrum?
El Desarrollo Guiado por Pruebas (TDD) se centra en garantizar que el código funcione según lo esperado para un comportamiento o caso de uso específico. En lugar de buscar la solución óptima desde el principio, el código y las pruebas se construyen de un modo iterativo, un requisito tras otro. Los developers en Scrum utilizan TDD para asegurar la cobertura de pruebas, mejorar la calidad del código, sentar las bases para su pipeline de integración y de entrega continua y asi respaldar la entrega continua.
Los beneficios de TDD en Scrum
- Posibilitar una innovación más rápida y una entrega continua debido a la robustez del código (aunque utilizar TDD no lo asegura al 100%).
- Hacer que el código sea flexible y extensible, permitiendo refactorizaciones o movimientos con un riesgo mínimo de romper el código.
- Las pruebas mismas son probadas, garantizando que cada nueva prueba pueda fallar.
- El código producido es, por diseño, fácil de probar.
- Se implementan los requisitos con poco o ningún esfuerzo desperdiciado, ya que solo se escribe la función necesaria.
- Reducir costes
- Facilitar y agilizar la refactorización y la reescritura
- Evitar errores y acoplamientos
- Mejorar la colaboración general del Scrum Team
- Aumentar la confianza en que el código funciona como se espera
- Mejorar los patrones de código
- Eliminar el miedo al cambio
¿Qué es el ciclo Red-Green-Refactor en TDD?
El ciclo TDD incorpora además de las tres reglas de TDD de “Uncle Bob” un paso de refactorización después de que las pruebas pasen. Los developers que utilizan TDD se refieren a este ciclo como el ciclo Red/Green/Refactor.
- Fase Roja: Se escribe una prueba que falla pensada para el requisito que estamos abordando, a veces esto incluye algunas pruebas de integración. Esto significa que vamos a realizar un test antes de escribir el código que satisfaga este requisito.
- Fase Verde: Se implementa el código mínimo y necesario para hacer pasar la prueba correctamente.
- Fase de Refactorización: Ahora es el momento de modificar el código para mejorarlo. Como mínimo, se elimina el código duplicado si lo hay. La eliminación de duplicaciones generalmente lleva a la abstracción. En general, las pruebas no deberían necesitar cambios durante esta fase.
El diseño a través del TDD
El TDD no solo se trata de pruebas, es principalmente sobre diseño. Se permite que las pruebas guíen el desarrollo del código de producción. A medida que las pruebas se vuelven más específicas, el código se vuelve más genérico. Además, el TDD es una de las prácticas de valor añadido cubiertas en cursos de Scrum o PSD (Professional Scrum Developer), ayudando a los developers a entregar incrementos potencialmente liberables al final de un Sprint.
Diferencia entre TDD, BDD y ATDD
Desarrollo guiado o dirigido por pruebas (TDD)
TDD es un enfoque que adopta un método de «Shift Left Testing» o “Test First”, centrado en construir el software de manera adecuada. El developer inicia escribiendo una prueba basada en un requisito específico. Luego, desarrolla el código necesario para que esa prueba sea superada. Posteriormente, puede reestructurar el código y generar una nueva prueba para el siguiente requisito. Este ciclo se conoce como el enfoque de Red-Green-Refactor, mencionado previamente. Se parte de la idea de que los criterios de aceptación ya han sido validados por un experto en el dominio de negocio. El objetivo es desarrollar lo justo para cumplir con el requisito conocido.
Desarrollo guiado por comportamientos (BDD)
BDD es una estrategia o técnica para identificar requisitos novedosos y entendimiento común sobre lo que quieren los usuarios y el comportamiento del usuario con el producto. Al practicar BDD, comenzamos por eliminar suposiciones sobre criterios de aceptación ya validados, iniciando el proceso mediante una interacción estrecha entre negocio y los desarrolladores. Esta interacción inicial, centrada en las necesidades de negocio, valor aportado a los usuarios, nos permite adoptar un enfoque de «fuera hacia dentro» para desarrollar la solución adecuada. Esta sinergia puede convertirse en una especificación funcional si se ajusta al formato necesario para alguna de las herramientas de automatización de pruebas. En el contexto de Scrum, esta interacción podría ocurrir durante el refinamiento del Product Backlog, e incluso en esta actividad podemos utilizar el concepto de Three amigos que es muy buena práctica.
Es posible llevar a cabo BDD sin necesidad de implementar automatización. BDD y Cucumber no son sinónimos. Cucumber es simplemente una harramienta de automatización que puede emplearse para poner en práctica sus especificaciones BDD si así lo decide. Al automatizar estas especificaciones ejecutables, se está practicando el desarrollo dirigido por pruebas o criterios de aceptación (ATDD), que veremos a continuación.
Desarrollo Guiado por pruebas o criterios de aceptación (ATDD)
ATDD está relacionado con BDD, pero pone énfasis en la automatización de la especificación. Cuando alguien automatiza su especificación (a menudo derivada de BDD), está aplicando ATDD. Aunque BDD no se identifica con ninguna herramienta específica, Cucumber se menciona como una herramienta de automatización que puede usarse para automatizar las especificaciones de BDD. Cuando estas especificaciones se automatizan, se entra en el ámbito de ATDD.
Errores Comunes al utilizar TDD en Scrum Teams
Los errores individuales típicos
- Olvidar ejecutar las pruebas con regularidad
- Crear demasiadas pruebas de una sola vez
- Desarrollar pruebas demasiado extensas o generales
- Elaborar pruebas excesivamente simples, como omitir afirmaciones
- Realizar pruebas para código básico, como los accesorios
Los desafíos comunes en equipos
- Adopción parcial: solo algunos desarrolladores del equipo aplican TDD
- Mantenimiento deficiente del conjunto de pruebas, lo que a menudo resulta en un tiempo de ejecución excesivamente largo para el conjunto de pruebas
- Conjunto de pruebas desatendidas (es decir, raramente o nunca se ejecuta), a veces debido a un mantenimiento inadecuado y otras veces debido a cambios en la composición del equipo.
Ejemplo de TDD en ReactJS
Este ejemplo fue creado por ChatGPT-3 😉
Preparar el entorno
npx create-react-app tdd-react-example
cd tdd-react-example
npm install --save @testing-library/react @testing-library/jest-dom
Escribir el test
import React from 'react';
import { render, fireEvent } from '@testing-library/react';
import Counter from "./Counter"
test('renders a counter, starts at 0 and can be incremented', () => {
const { getByText } = render();
// Initial render should display 0
expect(getByText('0')).toBeInTheDocument();
// Find the button and click it
const button = getByText('Increment');
fireEvent.click(button);
// Counter should now be 1
expect(getByText('1')).toBeInTheDocument();
});
Crear el componente
import React, { useState } from 'react';
function Counter() {
const [count, setCount] = useState(0);
return (
{count}
);}export default Counter;
Ejecutar el test
npm test
Refactorizar
Este paso es más relevante para características más grandes o más complejas. En TDD, una vez que tienes una prueba que pasa, puedes refactorizar tu código con la confianza de que tu prueba detectará cualquier regresión. Como se mencionó antes, en este ejemplo simple, puede que no haya mucho que refactorizar, pero es un paso esencial a tener en cuenta.