El desarrollo guiado por pruebas (TDD, por sus siglas en inglés) es una forma de crear software en la que los desarrolladores escriben una pequeña prueba automatizada antes que el código de la funcionalidad. Al principio, esa nueva comprobación falla porque todavía no se ha construido nada. Después, los desarrolladores escriben solo el código que la prueba exige, ordenan el resultado y pasan a la siguiente regla.
En la mañana del 5 de diciembre de 2025, un pequeño error de programación dejó fuera de servicio Shopify, Zoom, LinkedIn y las webs de varios bancos. Durante unos 25 minutos, sus clientes solo vieron páginas de error donde debían aparecer los pagos, las reuniones y los saldos de sus cuentas. El fallo estaba en Cloudflare, la empresa que transporta y protege el tráfico de todos esos sitios. Según la propia Cloudflare, el código defectuoso había pasado desapercibido durante muchos años, porque solo se ejecutaba en una situación que nunca se había dado hasta esa mañana.
Escribir la prueba primero parece hacerlo al revés, pero ayuda a detectar errores en código que rara vez se ejecuta. En TDD, cada fragmento de código se escribe para superar una prueba, así que incluso un camino poco habitual dentro del programa se ha probado antes del lanzamiento. Aun así, solo existen pruebas para los casos que alguien pensó en comprobar. Cada prueba que sí existe se queda en el proyecto y vuelve a ejecutarse tras cada cambio, lo que convierte el TDD en la primera capa de las pruebas automatizadas de un producto.
Siga leyendo para conocer el ciclo rojo-verde-refactorización, la diferencia con el desarrollo guiado por comportamiento (BDD), cómo encaja la IA y qué papel desempeña QA.
¿Qué es el desarrollo guiado por pruebas?
En el desarrollo guiado por pruebas, el producto crece en piezas pequeñas, y cada una debe superar una comprobación escrita de antemano. La definición formal procede del glosario del International Software Testing Qualifications Board (ISTQB), que describe el método así: «Técnica de desarrollo de software en la que se desarrollan los casos de prueba, se automatizan y luego se desarrolla el software de forma incremental para que pase esos casos de prueba».
El ingeniero de software Kent Beck popularizó la práctica en su libro de 2002 Test Driven Development: By Example. El método pertenece a los desarrolladores, y sus pruebas se guardan justo al lado del código del producto. Cada comprobación cubre una sola pieza pequeña de lógica, como el cálculo de un recargo por demora. Antes de empezar, un desarrollador suele anotar los casos que una funcionalidad tiene que resolver. Esas notas se convierten después en pruebas, una a una.
Cómo funciona el ciclo rojo-verde-refactorización del TDD
Los desarrolladores suelen llamar a este ciclo TDD red green refactor (rojo, verde, refactorización), por los colores que muestran la mayoría de las herramientas de pruebas. El rojo marca una prueba que falla, y el verde, una que pasa. Imagine una aplicación de reservas para una peluquería con una regla: quien cancela con al menos 24 horas de antelación recibe un reembolso completo. Construir esa regla lleva tres pasos, repetidos en bucle:
- Rojo (red): El desarrollador escribe primero una prueba que cancela una reserva 48 horas antes de la cita y espera recuperar el precio completo. La función de reembolso aún no existe, así que la prueba falla y la herramienta muestra rojo. Ese fallo demuestra que la prueba realmente puede detectar un problema.
- Verde (green): A continuación, el desarrollador escribe el mínimo código imprescindible para que la prueba pase, por tosco que parezca.
- Refactorización (refactor): Refactorizar significa mejorar cómo está escrito el código sin cambiar lo que hace. Con todas las pruebas en verde, el desarrollador lo ordena: nombres más claros, sin líneas duplicadas y una estructura más sencilla. Las pruebas en verde confirman después que nada se ha roto durante la limpieza.
Después, el bucle vuelve a empezar con una segunda prueba: una cancelación tres horas antes de la cita, que no debería recibir reembolso.
Cada ciclo es pequeño a propósito, así que una sola funcionalidad puede requerir decenas de ellos. Lo que queda al final es un conjunto de pruebas unitarias: comprobaciones automatizadas y rápidas que examinan, cada una, una pieza de código. Los equipos suelen organizar las pruebas en una pirámide de pruebas, con muchas pruebas pequeñas y rápidas en la base y unos pocos recorridos lentos por trayectos completos del usuario en la cima. Con los meses, las pruebas unitarias del TDD se acumulan por cientos y forman la amplia base de esa pirámide.
Si lee código, así es más o menos como se ven los dos primeros pasos en Python con pytest, una herramienta de pruebas muy popular:
# Rojo: se escribe primero; esta prueba falla porque refund_for() aún no existe
def test_full_refund_when_cancelled_two_days_ahead():
assert refund_for(hours_before=48, price=60) == 60
# Verde: el código más sencillo que hace pasar la prueba
def refund_for(hours_before, price):
return priceLa versión verde ignora por completo la regla de las 24 horas, y es a propósito. La prueba de la cancelación tres horas antes falla con este código y obliga al desarrollador a escribir la lógica de reembolso real.
Por qué el TDD es la forma más literal de las pruebas shift left
Las pruebas shift left acercan los controles de calidad al inicio de un proyecto. Así, los problemas se detectan poco después de introducirse. Los equipos suelen conseguirlo revisando los requisitos pronto y ejecutando pruebas automatizadas con cada cambio. El desarrollo guiado por pruebas lleva la idea tan lejos como el código lo permite. Cada prueba se escribe antes que la funcionalidad que cubre, así que, en principio, no existe código de producto sin su prueba.
Ese orden reduce a unos minutos el tiempo entre un error y su descubrimiento. El desarrollador que escribió la línea defectuosa todavía la tiene delante, así que corregirla lleva un momento. Si el error aparece en una ronda de pruebas posterior, alguien tiene que reproducirlo, rastrear su origen y cambiar código que quizá ya usan otras funcionalidades.
TDD vs BDD: en qué se diferencian los dos métodos de prueba primero
El BDD nació del TDD y mantiene la idea de escribir la prueba primero, pero dirige sus pruebas a otro lector. Al comparar TDD vs BDD, destacan cuatro diferencias:
- Quién lee las pruebas: Los desarrolladores escriben las pruebas de TDD en un lenguaje de programación, sobre todo para colegas que también programan. Los escenarios de BDD son frases cotidianas que siguen el patrón Given/When/Then (Dado/Cuando/Entonces). Los product owners y los testers pueden revisar ese texto sin leer código.
- Cuánto cubre una prueba: Una prueba de TDD comprueba una pequeña regla dentro del código. Un escenario de BDD describe un comportamiento completo que un usuario notaría, por ejemplo: «Dado un cliente que ha olvidado su contraseña, Cuando pide un enlace para restablecerla, Entonces le llega un enlace por correo electrónico que caduca al cabo de una hora».
- Cómo encajan los métodos: Debajo de ese escenario de la contraseña hay varias pruebas de TDD: una crea el enlace de restablecimiento, otra aplica el límite de una hora y otra rechaza cualquier segundo uso. Los equipos que combinan ambos métodos suelen trabajar en dos bucles, empezando por un escenario de BDD que falla. Después, los desarrolladores ejecutan ciclos de TDD sobre cada pieza hasta que todo el comportamiento funciona.
- Qué protege cada método: El TDD protege de errores la lógica interna del código. El BDD mantiene de acuerdo a quienes piden una funcionalidad y a los desarrolladores que la construyen.
La pregunta decisiva es quién necesita leer las pruebas. El TDD por sí solo basta cuando solo lo hacen los desarrolladores. Cuando las personas de negocio tienen que aprobar cómo se comportan las funcionalidades, el BDD añade una capa legible por encima.
Cómo se compara el TDD con escribir las pruebas después del código
La alternativa habitual al TDD es el desarrollo con pruebas a posteriori (test-after development), en el que los programadores construyen primero una funcionalidad y añaden las pruebas cuando el código ya funciona. Ambos métodos pueden acabar con un número de pruebas parecido. Sin embargo, el orden cambia lo que comprueban esas pruebas y cómo queda el código.
Momento de las pruebas
Antes de cada pequeña pieza de código
Después de que la funcionalidad funcione
Base de las pruebas
Las reglas que debe cumplir la funcionalidad
El código que ya existe
Riesgo de pruebas omitidas
Bajo, porque no se escribe código sin una prueba que falle
Mayor, porque es fácil prescindir de las pruebas cuando se acerca una fecha límite
Efecto en la estructura del código
Empuja a los desarrolladores hacia piezas pequeñas, fáciles de comprobar una a una
El código terminado a veces necesita retoques antes de poder probarse
El desarrollo guiado por pruebas aporta tres ventajas principales:
- Un diseño más limpio: Decidir cómo se usará una funcionalidad antes de escribirla produce un código más sencillo que el siguiente desarrollador puede seguir.
- Una red de seguridad duradera: Las comprobaciones acumuladas siguen ejecutándose a medida que el producto crece, así que un cambio que rompe un comportamiento anterior falla de inmediato.
- Protección para las reglas delicadas: Precios, facturación y permisos reciben una comprobación por cada caso que el desarrollador haya enumerado.
El método también tiene costes claros:
- Un arranque más lento: Escribir las pruebas por adelantado añade tiempo antes de que una nueva funcionalidad funcione.
- Mal encaje con código antiguo: Los proyectos sin pruebas a menudo necesitan reestructurarse solo para que sea posible probarlos.
- Puntos ciegos en el aspecto y la experiencia de uso: El diseño visual y la facilidad de uso quedan fuera de lo que una pequeña comprobación a nivel de código puede juzgar.
¿Cómo encaja la IA en el desarrollo guiado por pruebas?
Los asistentes de programación con IA y el TDD funcionan bien juntos, siempre que cada parte mantenga su propio trabajo. El desarrollador decide qué debe hacer el código y lo deja escrito en forma de pruebas. Después, el asistente produce código hasta que todas esas pruebas pasan. Así se reparte el trabajo en un programa de fidelización en el que los clientes ganan un punto por cada 10 $ completos que gastan:
- El desarrollador escribe las pruebas. Una prueba espera 9 puntos para un pedido de 95 $, una segunda quiere 10 para exactamente 100 $, y una tercera comprueba que un café de 9 $ no da ningún punto.
- El asistente escribe un borrador del código. Supongamos que su primer intento redondea los 95 $ a 10 puntos. La prueba en rojo señala ese error en segundos, y el asistente lo corrige.
- El asistente propone casos adicionales. Por ejemplo, puede preguntar qué pasa con los puntos tras un reembolso o en un pedido pagado con una tarjeta regalo. El desarrollador decide cuáles de esos casos forman parte de la regla.
- El desarrollador revisa el resultado. Esa revisión incluye confirmar que las pruebas originales no se han tocado.
El reparto deja de funcionar cuando el asistente escribe tanto las pruebas como el código. Si la herramienta interpreta mal la regla, sus pruebas coincidirán con su propio error, y todas las comprobaciones seguirán pasando. Un asistente también puede convertir una prueba roja en verde relajándola, por ejemplo, borrando el caso de los 95 $. Por eso, las pruebas deben escribirlas y aprobarlas personas, aunque una herramienta de IA produzca la mayor parte del código.
¿Qué papel tiene QA junto al TDD?
Las pruebas de TDD demuestran que el código hace lo que su desarrollador pretendía. Sin embargo, no pueden revelar si el requisito se entendió bien, porque la misma persona escribe la prueba y el código. Por ejemplo, supongamos que un periodo de prueba gratuito debe durar 14 días naturales y el desarrollador lo entiende como 14 días laborables. La prueba y el código coincidirán a la perfección, y ambos estarán mal.
Un TDD sólido significa que llegan menos errores básicos de lógica a los testers. Así, un equipo de QA puede centrarse en los riesgos que quedan fuera de las propias pruebas de un desarrollador:
- Requisitos antes de la primera prueba: Al inicio de un proyecto, los ingenieros de QA revisan los requisitos y los criterios de aceptación, la lista de comprobación que decide cuándo está terminada una funcionalidad. Los especialistas de QAwerk también revisan la lista de pruebas de los desarrolladores en busca de casos que falten, como un cliente que se registra dos veces con el mismo correo electrónico. El TDD por sí solo no puede cerrar esas brechas, ya que cada prueba parte de la interpretación que una persona hace del requisito.
- Conexiones entre funcionalidades: Las pruebas de integración comprueban cómo se comportan las partes por separado una vez combinadas. Un pago confirmado, por ejemplo, debería activar la suscripción del cliente. Una prueba de TDD normalmente no puede verificar ese vínculo, ya que examina una pieza de código de forma aislada.
- Tiempos y condiciones reales: Los ingenieros de QA prueban el producto en funcionamiento tal y como lo usa la gente. Por ejemplo, dos clientes podrían editar el mismo pedido a la vez mientras la red va lenta. Las pruebas unitarias rara vez recrean esa situación, porque se ejecutan en segundos en un solo ordenador.
- Facilidad de uso: En las pruebas exploratorias, un tester recorre la aplicación libremente, sin guion. Por el camino, el especialista puede notar que a los clientes les cuesta encontrar el botón de cancelar. Ninguna comprobación a nivel de código puede juzgar eso, porque la confusión es una reacción humana.
¿Es el TDD adecuado para su producto?
Con el desarrollo guiado por pruebas, cada nueva funcionalidad tarda más en construirse al principio. A cambio, cada regla que define el equipo se entrega con su propia prueba, y el código sigue siendo fácil de cambiar. Para un producto pensado para crecer durante años, ese intercambio suele compensar.
Nuestros ingenieros de QA continúan donde terminan esas pruebas, desde la revisión de requisitos antes de empezar a programar hasta las pruebas de integración y usabilidad del software terminado. Ese trabajo puede empezar en la fase de planificación o tras años de una suite de TDD madura.
¿Necesita reforzar su capacidad de pruebas? Llámenos hoy mismo.
Preguntas frecuentes
¿Qué es el desarrollo guiado por pruebas en términos sencillos?
El desarrollo guiado por pruebas es un método de programación en el que los desarrolladores describen el comportamiento esperado de una funcionalidad en una prueba automatizada antes de escribir su código. Después, el trabajo avanza en bucles cortos. Primero llega una prueba que falla (rojo), luego el código más pequeño que la hace pasar (verde) y, por último, una limpieza que mantiene la prueba en verde (refactorización).
¿El TDD es lo mismo que las pruebas unitarias?
El TDD y las pruebas unitarias se solapan, pero responden a preguntas distintas. Las pruebas unitarias describen qué se comprueba: funciones individuales y otras partes pequeñas de un programa, probadas de forma aislada. El TDD describe el momento: esas pruebas van primero, como una descripción escrita que el código debe cumplir después. Muchos equipos añaden pruebas unitarias cuando el trabajo ya está terminado y nunca practican TDD.
¿El TDD ralentiza el desarrollo?
A corto plazo, el TDD suele añadir tiempo, porque los desarrolladores escriben una prueba antes de cada pequeña parte de una funcionalidad. A lo largo de la vida de un producto, gran parte de ese tiempo se recupera. El desarrollador que comete un error lo detecta antes de que nadie construya sobre ese código, y los cambios posteriores rompen menos funcionalidades existentes. El balance favorece al software de larga vida frente a los prototipos rápidos.
¿El TDD sustituye a las pruebas de QA?
El TDD no sustituye a las pruebas de QA, porque ambos buscan problemas distintos. Como práctica de desarrollo, el TDD confirma que cada unidad de código se comporta como su autor esperaba. Las pruebas de QA miran el producto como lo haría un cliente: si los requisitos eran correctos, si las funcionalidades funcionan juntas y si el software aguanta en dispositivos, redes y tráfico reales.
¿Pueden las herramientas de IA seguir el desarrollo guiado por pruebas?
Los asistentes de programación con IA pueden seguir un bucle de prueba primero: leen una prueba que falla, escriben código, vuelven a ejecutar la prueba y repiten hasta que pasa. Así, las pruebas se convierten en un control práctico y automático del código generado por IA. Sin embargo, las propias pruebas deberían venir de una persona que conozca las reglas de negocio, ya que un asistente solo puede adivinar qué se supone que debe hacer el software.
Descubra cómo ayudamos a Kazidomi a acelerar la entrega de funcionalidades con la automatización de pruebas y a convertirse en la startup número 1 de Bélgica
