TDD: Difference between revisions

Jump to navigation Jump to search
← Older edit
Mberne (talk | contribs)
Bureaucrats, Interface administrators
3,012 edits
No edit summary
 
(5 intermediate revisions by the same user not shown)
Line 1: Line 1:
'''Desarrollo guiado por pruebas o ''Test-driven development'' (TDD)''' es una práctica para desarrollo de software consistente en la repetición de un ciclo breve en el que primero se codifica un caso para automatizar la prueba de la función que se quiere programar. A continuación escribe un código mínimo que debe pasar esa prueba, y a partir de ahí se va refactorizando el código hasta el nivel de producto deseado.
{{Meta-bok|min=5}}
El '''desarrollo guiado por pruebas''' (''Test-Driven Development'', TDD) es una práctica de ingeniería de software que invierte el orden habitual de trabajo: primero se escribe una prueba automatizada que describe el comportamiento que se quiere implementar, después se escribe el código mínimo necesario para que esa prueba pase, y finalmente se [[Refactorización|refactoriza]] el código para mejorar su estructura sin cambiar su comportamiento. Este ciclo breve se repite continuamente durante el desarrollo.


TDD traduce los requisitos a pruebas, de forma que el que el código pase las pruebas es la garantía de que el producto cumple con los requisitos.
La práctica es atribuida a Kent Beck, quien la describió como parte central de [[Extreme programming|Extreme Programming]] (1999) y la desarrolló en detalle en su libro ''Test-Driven Development: By Example'' (2003). Beck describía TDD como una forma de generar diseños simples e inspirar confianza en el código.
== El ciclo rojo-verde-refactorizar ==
El ciclo de TDD se describe habitualmente con tres colores:
* '''Rojo:''' escribe una prueba que falla porque la funcionalidad aún no existe. La prueba fallida (roja) es el punto de partida: define qué debe hacer el código.
* '''Verde:''' escribe el código mínimo necesario para que la prueba pase. Solo el código mínimo: nada más, aunque parezca "feo" o provisional.
* '''Refactoriza:''' mejora la estructura interna del código sin cambiar su comportamiento externo. Las pruebas garantizan que la refactorización no ha roto nada.
Este ciclo dura minutos, no horas. La disciplina de mantenerse en ciclos cortos es lo que hace efectivo a TDD.


La principal cualidad de TDD es que genera diseños simples e inspira confianza, según afirma Kent Beck, a quien se le atribuye la introducción o en ocasiones el redescubrimiento de esta práctica.
== Qué aporta TDD ==
* '''Cobertura de pruebas desde el principio:''' como las pruebas se escriben antes que el código, cada funcionalidad tiene su prueba desde el primer día. No hay código sin prueba.
* '''Diseño emergente:''' escribir la prueba antes de implementar obliga a pensar en cómo se usará el código (su interfaz) antes de pensar en cómo funcionará internamente. Esto tiende a producir diseños más simples y desacoplados.
* '''[[Refactorización]] segura:''' con una suite de pruebas completa, el equipo puede refactorizar con confianza. Si algo se rompe, las pruebas lo detectan inmediatamente.
* '''Reducción de [[Deuda técnica|deuda técnica]]:''' el ciclo rojo-verde-refactorizar incorpora la mejora continua del código como parte del proceso normal de desarrollo, no como una tarea separada que "se hará cuando haya tiempo".
* '''Documentación ejecutable:''' las pruebas describen el comportamiento esperado del sistema de forma precisa y verificable. Son una forma de documentación que no puede quedar desactualizada: si el código cambia, las pruebas lo detectan.


== Relación con BDD ==
El '''Behavior-Driven Development''' (BDD) es una extensión de TDD que usa un lenguaje más expresivo (como Gherkin: Dado / Cuando / Entonces) para escribir las pruebas de forma que sean comprensibles también para personas no técnicas. Los [[Criterios de aceptación|criterios de aceptación]] escritos en formato BDD son directamente ejecutables como pruebas. TDD y BDD son complementarios: TDD se aplica a nivel de unidad, BDD a nivel de comportamiento del sistema.
== TDD con herramientas de IA ==
La IA generativa está cambiando cómo los equipos aplican TDD en la práctica:
* '''Generación de pruebas asistida:''' los asistentes de código (GitHub Copilot, Cursor) pueden sugerir pruebas unitarias a partir de la descripción de una función. Esto acelera la escritura de pruebas para código ya existente, aunque no sigue estrictamente el orden de TDD.
* '''TDD con IA como par:''' algunos equipos usan la IA para generar el código que pasa una prueba ya escrita por el desarrollador, manteniendo así el ciclo rojo-verde-refactorizar con asistencia.
<div class="bok-aviso">
'''El mayor riesgo de usar IA en TDD es invertir el ciclo:''' que la IA genere el código primero y las pruebas después, como verificación en lugar de como especificación. Esto elimina el beneficio de diseño que aporta TDD: escribir la prueba primero obliga a pensar en el comportamiento esperado antes de pensar en la implementación. Con IA generando el código primero, ese pensamiento previo desaparece y el código tiende a ser más complejo y acoplado.
</div>
== Error frecuente ==
<div class="bok-aviso">
'''Aplicar TDD solo a funcionalidades nuevas y no a la corrección de errores.''' Un error en producción es una prueba que falta: el comportamiento incorrecto no estaba cubierto. La práctica recomendada es escribir primero una prueba que reproduzca el error, verificar que falla (rojo), corregir el código hasta que pase (verde), y entonces refactorizar. Esto garantiza que ese error no volverá a ocurrir sin ser detectado.
</div>
== Referencias ==
* Beck, Kent. (2003). ''Test-Driven Development: By Example''. Addison-Wesley.
* Beck, Kent; Fowler, Martin. (1999). ''Planning Extreme Programming''. Addison-Wesley.
== Véase también ==
<div class="bok-tags">
[[Extreme programming]] [[Agilidad técnica]] [[Refactorización]] [[Pair programming]] [[Deuda técnica]] [[Criterios de aceptación]] [[Definición de hecho]]
</div>
<div class="bok-ecosistema">
<div class="texto">
<span class="titulo">'''¿Quieres avanzar en agilidad?'''</span>
<span class="sub">Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a [https://scrummanager.com/skillarena/ '''Skill Arena''']: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.</span>
</div>
<div class="botones">
<div class="bok-btn-outline">[https://www.scrummanager.com/website/c/calendar/show-courses.php Buscar convocatorias]</div>
<div class="bok-btn-filled">[https://scrummanager.com/club/ Club Agile]</div>
</div>
</div>
[[Category:Glosario de términos]]
[[Category:Glosario de términos]]
[[Category:Metodologías ágiles]]
[[Category:Prácticas técnicas]]
[[Category:Prácticas ágiles]]
Retrieved from "https://www.scrummanager.com/bok/index.php?title=TDD"