TDD: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
| (2 intermediate revisions by the same user not shown) | |||
| Line 5: | Line 5: | ||
== El ciclo rojo-verde-refactorizar == | == El ciclo rojo-verde-refactorizar == | ||
El ciclo de TDD se describe habitualmente con tres colores: | 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. | * '''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. | * '''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. | * '''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. | Este ciclo dura minutos, no horas. La disciplina de mantenerse en ciclos cortos es lo que hace efectivo a TDD. | ||
== Qué aporta TDD == | == 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. | |||
'''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. | ||
'''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. | ||
'''[[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". | ||
'''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. | ||
'''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 == | == Relación con BDD == | ||
| Line 21: | Line 21: | ||
== TDD con herramientas de IA == | == TDD con herramientas de IA == | ||
La IA generativa está cambiando cómo los equipos aplican TDD en la práctica: | 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. | |||
'''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. | ||
'''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"> | <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. | '''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> | </div> | ||
== Error frecuente == | == Error frecuente == | ||
<div class="bok-aviso"> | <div class="bok-aviso"> | ||