TDD - Revision history

Mberne: /* Referencias */

2026-05-19T14:59:56Z

Referencias

← Older revision		Revision as of 16:59, 19 May 2026
Line 33:		Line 33:
	</div>		</div>
	== Referencias ==		== Referencias ==
			* Beck, Kent. (2003). ''Test-Driven Development: By Example''. Addison-Wesley.
	Beck, Kent. (2003). ''Test-Driven Development: By Example''. Addison-Wesley.		* Beck, Kent; Fowler, Martin. (1999). ''Planning Extreme Programming''. Addison-Wesley.
	Beck, Kent; Fowler, Martin. (1999). ''Planning Extreme Programming''. Addison-Wesley.

	== Véase también ==		== Véase también ==

Mberne: /* El ciclo rojo-verde-refactorizar */

2026-05-14T08:50:19Z

El ciclo rojo-verde-refactorizar

← Older revision		Revision as of 10:50, 14 May 2026
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.

Mberne: /* Qué aporta TDD */

2026-05-14T08:50:08Z

Qué aporta TDD

← Older revision		Revision as of 10:50, 14 May 2026
Line 10:		Line 10:
	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 ==

Mberne: /* TDD con herramientas de IA */

2026-05-14T08:49:46Z

TDD con herramientas de IA

← Older revision		Revision as of 10:49, 14 May 2026
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">

Mberne at 08:49, 14 May 2026

2026-05-14T08:49:21Z

@@ 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}}
-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.
-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.
+'''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.
-==Véase también==
+== Relación con BDD ==
-*[[Adaptive Software Development]].
+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.
-*[[Lean Software Development]].
+== TDD con herramientas de IA ==
-*[[Personal Software Process]].
+La IA generativa está cambiando cómo los equipos aplican TDD en la práctica:
-*[[Crisis del software]].
-*[[Modelo original de Scrum para desarrollo de software]].
+'''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.
 [[Category:Glosario de términos]]
-[[Category:Metodologías ágiles]]
+[[Category:Prácticas técnicas]]

Mberne at 10:51, 12 January 2024

2024-01-12T10:51:14Z

← Older revision		Revision as of 12:51, 12 January 2024
Line 5:		Line 5:
	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.		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.

			==Véase también==
			*[[Adaptive Software Development]].
			*[[Lean Software Development]].
			*[[Personal Software Process]].
			*[[Crisis del software]].
			*[[Modelo original de Scrum para desarrollo de software]].
	[[Category:Glosario de términos]]		[[Category:Glosario de términos]]
	[[Category:Metodologías ágiles]]		[[Category:Metodologías ágiles]]

Mberne at 14:10, 21 December 2023

2023-12-21T14:10:03Z

← Older revision		Revision as of 16:10, 21 December 2023
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.		'''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.

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

Smanager at 14:04, 26 April 2021

2021-04-26T14:04:28Z

← Older revision		Revision as of 16:04, 26 April 2021
Line 6:		Line 6:

	[[Category:Glosario de términos]]		[[Category:Glosario de términos]]
	~~[[Category:Información complementaria: ingeniería del software]]~~
	[[Category:Metodologías ágiles]]		[[Category:Metodologías ágiles]]

Smanager at 19:24, 18 October 2016

2016-10-18T19:24:51Z

← Older revision		Revision as of 21:24, 18 October 2016
Line 7:		Line 7:
	[[Category:Glosario de términos]]		[[Category:Glosario de términos]]
	[[Category:Información complementaria: ingeniería del software]]		[[Category:Información complementaria: ingeniería del software]]
			[[Category:Metodologías ágiles]]

Smanager at 15:14, 9 September 2016

2016-09-09T15:14:16Z

← Older revision		Revision as of 17:14, 9 September 2016
Line 6:		Line 6:

	[[Category:Glosario de términos]]		[[Category:Glosario de términos]]
			[[Category:Información complementaria: ingeniería del software]]