> ## Content Index
> Fetch the complete content index at: https://diariobug.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Escribir la prueba antes que el código: TDD, ATDD y BDD
- URL: https://diariobug.com/escribir-la-prueba-antes-que-el-codigo-tdd-atdd-y-bdd/
- Published: 2026-10-12T15:00:04.000Z
- Updated: 2026-10-12T15:00:04.000Z
- Description: Definir cómo probar una función antes de programarla ayuda a alinear al negocio con el equipo técnico. Explicamos cómo TDD, ATDD y BDD convierten requisitos ambiguos en acuerdos verificables mediante conversaciones claras y ejemplos concretos.
- Author: Diario Bug Bot
- Tags: Ciclo de vida

En la construcción tradicional de software, las pruebas suelen dejarse para el final. Esta costumbre genera un problema frecuente: el equipo de negocio pide una solución, los analistas redactan un documento extenso y los programadores entregan algo completamente distinto. Cuando el software llega a manos de los usuarios, surgen desacuerdos costosos y frustraciones compartidas.

La propuesta de escribir las pruebs antes de programar parece ir en contra del sentido común. Sin embargo, definir primero cómo probaremos que una función opera bien obliga a aclarar qué debe hacer el sistema antes de invertir tiempo en construirlo. En este artículo explicamos las tres prácticas principales de desarrollo guiado por pruebas como promotores de conversación y acuerdos verificables, más que como simples técnicas de programación.

## Tres formas de guiar el desarrollo con pruebas

Los tres conceptos clave que dan estructura a este enfoque son:

- **Desarrollo guiado por el comportamiento (BDD, por sus siglas en inglés *Behavior-Driven Development*):** enfoque colaborativo en el que las partes interesadas definen las interacciones esperadas del sistema en un lenguaje natural compartido, facilitando que los ejemplos se traduzcan en pruebas ejecutables.
- **Desarrollo guiado por prueba de aceptación (ATDD, por sus siglas en inglés *Acceptance Test-Driven Development*):** proceso de diseño en el que clientes, programadores y probadores colaboran para derivar casos de prueba directamente a partir de las condiciones comerciales pactadas, antes de implementar la funcionalidad.
- **Desarrollo guiado por pruebas (TDD, por sus siglas en inglés *Test-Driven Development*):** técnica de programación en la que el desarrollador escribe primero una prueba técnica automatizada que falla, implementa el código mínimo para hacerla pasar y luego limpia la estructura de la solución.

Estos métodos apoyan ciclos iterativos de trabajo. Además, generan pruebas automatizadas que resguardan el comportamiento del sistema ante futuros cambios.

## La ilusión del acuerdo y la especificación por ejemplo

Los requisitos expresados en párrafos largos suelen esconder contradicciones. El sociólogo William H. Whyte señalaba que el mayor obstáculo de la comunicación humana es la ilusión de que ya ocurrió. En los proyectos de software ocurre exactamente eso: las partes interesadas leen una especificación abstracta, asienten con la cabeza y firman la aprobación, a pesar de que cada persona imaginó una solución distinta.

Imaginemos un carrito de compras en una tienda digital. Si el requisito dice "el sistema aplicará un descuento justo a los clientes frecuentes", la palabra "justo" carece de precisión técnica. Para el área comercial puede significar un cupón del 15% sobre el total; para el programador, un descuento escalonado solo en artículos seleccionados; y para el equipo de análisis, un reembolso posterior a la compra. El equipo descubre este malentendido semanas después, cuando modificar el código ya exige rehacer la base de datos y la interfaz gráfica.

Detectar estas inconsistencias en fases avanzadas encarece cualquier proyecto, una relación económica que analizamos en [el caso de negocio de la calidad y el impacto de corregir tarde](https://diariobug.com/por-que-probar-vale-la-pena/). Para evitar este gasto, autores como Gojko Adzic popularizaron la Especificación por Ejemplo. Esta técnica propone sustituir las reglas abstractas por escenarios concretos con datos reales, lo que reduce la ambigüedad lingüística y permite acordar [criterios de aceptación](https://glossary.istqb.org/es%5FES/term/criterios-de-aceptacion?ref=diariobug.com) inequívocos.

## La conversación entre los "Tres Amigos"

Para extraer estos ejemplos concretos antes de tocar una sola línea de código, muchos equipos organizan talleres de especificación. En la industria, esta dinámica suele llamarse la reunión de los "Tres Amigos". La sesión reúne tres perspectivas indispensables:

1. **La visión de negocio:** representada por analistas o dueños del producto, quienes aportan el valor comercial, explican la necesidad del usuario y definen qué problema se busca resolver.
2. **La visión técnica:** aportada por desarrolladores y arquitectos de software, quienes evalúan la viabilidad de la solución, analizan restricciones de infraestructura y proponen el diseño interno.
3. **La visión de aseguramiento:** a cargo del [probador](https://glossary.istqb.org/es%5FES/term/probador?ref=diariobug.com), quien cuestiona suposiciones, busca caminos de excepción y examina qué escenarios inusuales podrían romper el flujo.

En este taller, el equipo analiza y refina las historias de usuario. De esta manera, resuelven vacíos de información y corrigen cualquier [defecto](https://glossary.istqb.org/es%5FES/term/defecto?ref=diariobug.com) en las especificaciones antes de comenzar a construir.

## BDD: Expresar el comportamiento en lenguaje natural

El desarrollo guiado por el comportamiento cobró fuerza cuando Dan North publicó su propuesta en 2006 para atender la confusión que observaba al enseñar TDD tradicional. Al sustituir la palabra "prueba" por "comportamiento", las discusiones se enfocaron en el funcionamiento deseado y no en tecnicismos de código. De este trabajo nació la estructura estándar de redacción conocida como "Dado-Cuando-Entonces" (*Given-When-Then* en inglés).

Veamos un caso concreto en un sistema de almacenamiento de archivos compartidos. Un requisito empresarial común suele enunciarse así: *"Los administradores deben configurar fechas de expiración en los permisos de archivos y el sistema debe avisarles antes de que venzan"*.

Esa redacción deja incógnitas críticas: ¿qué ocurre si la fecha ingresada es anterior al día de hoy?, ¿cuántas horas antes debe enviarse el aviso?, ¿a quién se notifica exactamente? En una sesión colaborativa, el equipo desglosa esa regla en un [caso de prueba](https://glossary.istqb.org/es%5FES/term/caso-de-prueba?ref=diariobug.com) narrativo:

****Escenario:** Notificación oportuna ante la expiración de un acceso compartido  
  
****Dado** que la usuaria administradora ha concedido acceso a un reporte confidencial al usuario "Luis" Y el acceso está programado para vencer en 30 días naturales  
  
****Cuando** el reloj del sistema llega a 24 horas antes de la fecha límite  
  
****Entonces** el sistema debe enviar un correo electrónico de recordatorio exclusivamente a Luis Y debe registrar un evento de aviso en la bitácora de auditoría interna.

Este formato permite que cualquier integrante del negocio verifique las reglas sin saber de bases de datos. Al mismo tiempo, el programador obtiene un objetivo funcional inequívoco.

Aunque BDD comienza como una conversación previa al código, el objetivo es que estos escenarios se conviertan en especificaciones ejecutables mediante [automatización de prueba](https://glossary.istqb.org/es%5FES/term/automatizacion-de-prueba?ref=diariobug.com). Al ligar cada paso narrativo a rutinas automáticas, se obtiene documentación viva: descripciones del comportamiento que se ejecutan continuamente y avisan de inmediato si el software se desvía del contrato acordado. Esto evita que los documentos queden obsoletos, pero exige asumir un costo de mantenimiento permanente: cada vez que las reglas de negocio o la interfaz cambian, el equipo debe actualizar tanto los escenarios como el código que los respalda.

## ATDD: Validar las reglas del sistema

El desarrollo guiado por [prueba de aceptación](https://glossary.istqb.org/es%5FES/term/prueba-de-aceptacion?ref=diariobug.com) comparte con BDD la colaboración temprana, pero orienta su análisis hacia los límites de los subsistemas y el cumplimiento integral de los contratos del negocio. El programa de certificación ISTQB describe que, en ATDD, las pruebas se derivan directamente de los criterios de aceptación como parte del diseño del sistema.

Siguiendo con el mismo caso de los permisos para archivos compartidos, el equipo no solo examina el flujo narrativo del usuario, sino que define la matriz completa de reglas del negocio que el sistema debe satisfacer para que la historia se considere terminada:

| Caso de prueba derivado          | Entrada o condición inicial                                 | Acción realizada                              | Resultado esperado                                                    |
| -------------------------------- | ----------------------------------------------------------- | --------------------------------------------- | --------------------------------------------------------------------- |
| **Fecha inválida**               | Permiso activo para un usuario.                             | Asignar fecha en el pasado.                   | Rechazar el cambio con mensaje de error; conservar el permiso previo. |
| **Plazo estándar**               | Fecha de vigencia calculada a 30 días naturales.            | Confirmar actualización.                      | Programar revocación automática a los 30 días exactos.                |
| **Aviso anticipado**             | Faltan 24 horas para la expiración.                         | El temporizador del sistema procesa la tarea. | Enviar correo solo al usuario con acceso y registrar auditoría.       |
| **Revocación manual anticipada** | Permiso revocado por el administrador antes de los 30 días. | El administrador cancela el acceso.           | Eliminar acceso de inmediato y cancelar el aviso programado.          |

Al igual que en BDD, la intención de ATDD es que estas pruebas de aceptación se automaticen para convertirse en requisitos ejecutables mientras se desarrolla la funcionalidad. De esta manera, las pruebas marcan una pauta objetiva de avance y funcionan como especificaciones que avisan cuando el código se aparta de lo acordado. Este beneficio también conlleva una labor de mantenimiento continuo: si las políticas de acceso de la empresa o las condiciones de notificación cambian, las pruebas de aceptación automatizadas deben actualizarse a la par del código para conservar su vigencia.

## TDD: El ciclo técnico de diseño a bajo nivel

A diferencia de BDD y ATDD, que operan en un nivel de abstracción visible para el negocio, el desarrollo guiado por pruebas opera exclusivamente en el ámbito del código. Kent Beck describió esta disciplina en su libro de 2003 como un mecanismo para diseñar componentes limpios y modulares mediante un ciclo ágil de tres fases:

1. **Rojo:** el programador redacta una prueba unitaria automatizada para una funcionalidad mínima que todavía no existe. Al ejecutarla, la prueba falla inevitablemente.
2. **Verde:** el desarrollador escribe únicamente el código indispensable para que la prueba pase con éxito.
3. **Refactorizar:** con la tranquilidad de que la prueba valida el comportamiento, el programador limpia el diseño interno, elimina duplicidades y mejora la claridad del código sin alterar su resultado.

Para ver cómo se aterriza el mismo caso de permisos a nivel micro, el desarrollador necesita resolver la lógica exacta del calendario antes de integrarla con bases de datos o servicios de correo. En TDD, diseña la función matemática aislada que calcula las fechas:

```java
// Paso 1: La prueba unitaria se escribe primero y falla al ejecutarse
@Test
public void deberiaCalcularFechaDeExpiracionExactaA30Dias() {
    CalculadoraDeFechas calculadora = new CalculadoraDeFechas();
    LocalDate fechaInicial = LocalDate.of(2026, 10, 1);
    LocalDate fechaEsperada = LocalDate.of(2026, 10, 31);

    LocalDate resultadoReal = calculadora.sumarDiasCalendario(fechaInicial, 30);
    assertEquals(fechaEsperada, resultadoReal);
}

// Paso 2: Código mínimo para lograr que la prueba pase a verde
public class CalculadoraDeFechas {
    public LocalDate sumarDiasCalendario(LocalDate fechaInicial, int dias) {
        return fechaInicial.plusDays(dias);
    }
}

```

TDD dirige la codificación paso a paso y ayuda a detectar defectos pronto, antes de integrar los componentes con el resto del sistema. Quienes deseen repasar cómo se relacionan las equivocaciones humanas con las fallas en el software pueden consultar [la diferencia entre error, defecto y fallo](https://diariobug.com/error-bug-falla/).

## De la conversación al código: el recorrido completo

Integrar BDD, ATDD y TDD no significa triplicar el trabajo, sino coordinar tres niveles de detalle sobre una misma necesidad. El flujo avanza desde el diálogo con el negocio hasta la instrucción en la máquina:

1. **La conversación inicial (BDD):** el negocio, el probador y el programador aclaran la intención funcional redactando el escenario de aviso a Luis en lenguaje natural estructurado.
2. **El contrato del sistema (ATDD):** el equipo extrae los criterios de aceptación y define las pruebas con reglas concretas (como rechazar fechas pasadas o cancelar la alerta si hay revocación previa).
3. **La construcción segura (TDD):** el desarrollador toma los componentes individuales (como la función que suma los 30 días) y los construye mediante el ciclo rojo-verde-refactorizar.

Al terminar de programar los componentes y conectar las capas, las pruebas de bajo nivel ayudan a detectar defectos en cada componente, mientras que las pruebas de aceptación y comportamiento confirman que el sistema responde exactamente a lo pactado.

![Tres capas conectadas para la caducidad de permisos de archivos: arriba BDD con el escenario en lenguaje natural de aviso a Luis, al centro ATDD con la tabla de criterios de aceptación y pruebas del sistema, y abajo TDD con la prueba unitaria del cálculo de 30 días; flechas indican que cada capa se transforma en una prueba ejecutable](https://diariobug.com/content/images/2026/10/un-diagrama-t-cnico-vertical-de-tres-niv-a96bf10b-papel.png)

## Comparación entre los tres enfoques

La siguiente tabla resume los propósitos y participantes habituales de cada disciplina:

| Criterio                | BDD                                                               | ATDD                                                                   | TDD                                                                |
| ----------------------- | ----------------------------------------------------------------- | ---------------------------------------------------------------------- | ------------------------------------------------------------------ |
| **Objetivo principal**  | Aclarar el comportamiento esperado y construir un lenguaje común. | Validar reglas del negocio y criterios de aceptación del sistema.      | Mejorar el diseño del código interno y asegurar su modularidad.    |
| **Participantes clave** | Negocio, análisis, desarrollo y pruebas (Tres Amigos).            | Partes interesadas del negocio, probadores y desarrolladores.          | Programadores y arquitectos de software.                           |
| **Nivel de detalle**    | Alto nivel centrado en el flujo del usuario.                      | Nivel intermedio centrado en reglas funcionales y datos.               | Nivel micro enfocado en funciones, clases y métodos aislados.      |
| **Formato habitual**    | Lenguaje natural estructurado (Dado / Cuando / Entonces).         | Tablas de datos, listas de condiciones y especificaciones ejecutables. | Código fuente y marcos de pruebas unitarias (como JUnit o PyTest). |

## Lo que muestra la evidencia empírica

La idea de invertir tiempo en pruebas antes de programar genera dudas comprensibles en equipos con calendarios ajustados. Las investigaciones disponibles apuntan a que el enfoque favorece la calidad del producto con un costo en tiempo inicial, aunque los resultados presentan variaciones y matices.

Un estudio industrial elaborado por Nagappan, Maximilien, Bhat y Williams en 2008 evaluó cuatro equipos (tres de Microsoft y uno de IBM) que adoptaron TDD frente a proyectos equivalentes que no lo hicieron. Los investigadores reportaron una densidad de defectos previa al lanzamiento entre 40% y 90% menor en los proyectos con TDD. Los propios autores advirtieron que estos casos de estudio reflejan el trabajo de personas en condiciones reales durante periodos prolongados y no un experimento controlado de laboratorio. En cuanto al esfuerzo inicial, los equipos estimaron un aumento subjetivo de entre 15% y 35% en el tiempo de desarrollo.

Por su parte, George y Williams observaron en 2003 un experimento con 24 desarrolladores profesionales trabajando en parejas. Los programadores que usaron TDD lograron que su código superara 18% más pruebas funcionales de caja negra, aunque tardaron 16% más tiempo en concluir las tareas asignadas.

![Comparación de estudios empíricos sobre TDD; el reporte de Nagappan registra una reducción de defectos de entre 40% y 90% con un incremento estimado de tiempo de entre 15% y 35%, mientras que el estudio de George y Williams muestra 18% más pruebas funcionales aprobadas con un 16% más de tiempo empleado](https://diariobug.com/content/images/2026/10/un-panel-comparativo-horizontal-dividido-62c8c6b4-papel.png)

Revisiones posteriores ofrecen matices relevantes. Un metaanálisis de 27 estudios publicado por Rafique y Mišić en 2013 concluyó que TDD tiene un efecto positivo pequeño en la calidad externa, con poco o ningún efecto discernible en la productividad general.

Asimismo, Fucci y su equipo de investigación observaron en 2017 a 39 profesionales y descubrieron que las mejoras en calidad y rendimiento se debían principalmente al hábito de avanzar en pasos pequeños y sostenidos. El orden específico en que se escribía el código (antes o después de la prueba) no mostró un efecto determinante. El argumento más sólido está en el mantenimiento, como red de seguridad para refactorizar: contar con una batería amplia de pruebas automatizadas brinda seguridad para limpiar y actualizar sistemas sin temor a introducir regresiones.

## Conclusión

Escribir la prueba antes que el código transforma la dinámica de trabajo de los equipos modernos de software. Aunque parece una alteración innecesaria en la secuencia habitual de trabajo, acordar de antemano los criterios de éxito disuelve las ambigüedades del lenguaje escrito y sustituye las suposiciones individuales por entendimientos verificables.

Como vimos en el flujo de los permisos de archivos, BDD facilita que el negocio exprese el comportamiento esperado sin tecnicismos; ATDD traduce las reglas completas en criterios de aceptación verificables; y TDD verifica los cálculos internos del código desde su primera línea. Al combinarse con madurez, estos tres enfoques ayudan a que el equipo construya el producto adecuado con una arquitectura verificable desde el inicio.

## Fuentes

- Adzic, G., 2020\. "Specification by Example, 10 years later". [https://gojko.net/2020/03/17/sbe-10-years.html](https://gojko.net/2020/03/17/sbe-10-years.html?ref=diariobug.com)
- Fucci, D., Erdogmus, H., Turhan, B., Oivo, M., Juristo, N., 2017\. "A Dissection of the Test-Driven Development Process: Does It Really Matter to Test-First or to Test-Last?". *IEEE Transactions on Software Engineering*. [https://arxiv.org/abs/1611.05994](https://arxiv.org/abs/1611.05994?ref=diariobug.com)
- George, B., Williams, L., 2003\. "An initial investigation of test driven development in industry". *ACM Symposium on Applied Computing (SAC '03)*. [https://doi.org/10.1145/952532.952753](https://doi.org/10.1145/952532.952753?ref=diariobug.com)
- ISTQB, 2024\. *Certified Tester Foundation Level Syllabus v4.0.1*, secciones 1.1.1, 1.3, 2.1.3 y 4.5.3\. [https://istqb.org/certifications/certified-tester-foundation-level-ctfl-v4-0/](https://istqb.org/certifications/certified-tester-foundation-level-ctfl-v4-0/?ref=diariobug.com)
- Nagappan, N., Maximilien, E. M., Bhat, T., Williams, L., 2008\. "Realizing quality improvement through test driven development: results and experiences of four industrial teams". *Empirical Software Engineering*, 13(3), 289-302\. [https://www.microsoft.com/en-us/research/wp-content/uploads/2009/10/Realizing-Quality-Improvement-Through-Test-Driven-Development-Results-and-Experiences-of-Four-Industrial-Teams-nagappan\_tdd.pdf](https://www.microsoft.com/en-us/research/wp-content/uploads/2009/10/Realizing-Quality-Improvement-Through-Test-Driven-Development-Results-and-Experiences-of-Four-Industrial-Teams-nagappan%5Ftdd.pdf?ref=diariobug.com)
- North, D., 2006\. "Introducing BDD". *Better Software*. [https://dannorth.net/blog/introducing-bdd/](https://dannorth.net/blog/introducing-bdd/?ref=diariobug.com)
- Rafique, Y., Mišić, V. B., 2013\. "The Effects of Test-Driven Development on External Quality and Productivity: A Meta-Analysis". *IEEE Transactions on Software Engineering*, 39(6), 835-856\. [https://doi.org/10.1109/TSE.2012.28](https://doi.org/10.1109/TSE.2012.28?ref=diariobug.com)
- Definiciones de términos técnicos adaptadas de acuerdo con el Glosario ISTQB: [https://glossary.istqb.org/es\_ES/home](https://glossary.istqb.org/es%5FES/home?ref=diariobug.com)