¿Qué es TDD y como utilizarlo en equipos Scrum?

24/08/2023
El TDD o desarrollo dirigido por pruebas es más que un enfoque de "prueba primero". Se trata de escribir una prueba que falle y luego escribir el código necesario para que pase. Es esencial tomar pequeños pasos para garantizar la eficiencia y precisión del proceso.
testing con TDD

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.

haciendo pruebas de TDD y BDD

¿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

diferencia entre tdd bdd atdd

¿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.

¿Te ha gustado este contenido?

¡Valora este contenido!

Promedio de puntuación 5 / 5. Recuento de votos: 1

Hasta ahora, ¡no hay votos!. Sé el primero en puntuar este contenido.

Otras publicaciones

Hablemos de complejidad

Hablemos de complejidad

 Pero, ¿sabemos qué es la complejidad?, ¿somos capaces de trabajar en entornos complejos? , es más, ¿somos conscientes de en qué medida afecta dicha...

leer más
Apúntate a la newsletter

Apúntate a la newsletter

Manténte informado sobre todo lo relacionado con Agile Product Management, Scrum, Management 3.0 y Kanban

¡Mensaje enviado!

Applying Flow Metrics for Scrum

By ProKanban.org

Código de descuento (21 %) QAF1UZZ1

You have Successfully Subscribed!