Test Driven Development - Historial de revisiones

189.178.32.69: /* Ciclo de desarrollo TDD */

2010-03-10T19:15:51Z

‎Ciclo de desarrollo TDD

201.251.182.130: /* Ver también */

2009-09-01T19:19:49Z

‎Ver también

201.251.185.130 en 14:39 31 ago 2009

2009-08-31T14:39:47Z

201.251.185.130: /* Ver también */

2009-06-26T20:06:40Z

‎Ver también

80.33.234.40 en 07:24 6 may 2009

2009-05-06T07:24:49Z

201.251.185.130: /* Ciclo de desarrollo TDD */

2008-09-18T13:08:12Z

‎Ciclo de desarrollo TDD

200.125.124.96 en 14:41 31 ago 2008

2008-08-31T14:41:38Z

201.251.185.130 en 16:53 29 ago 2008

2008-08-29T16:53:59Z

Admin: /* Ciclo de desarrollo TDD */

2008-07-27T13:39:44Z

‎Ciclo de desarrollo TDD

Admin en 13:38 27 jul 2008

2008-07-27T13:38:58Z

@@ Línea 21: / Línea 21: @@
 # '''Escribir el código haciendo que pase la prueba'''. Este paso fuerza al programador a tomar la perspectiva de un cliente considerando el código a través de sus interfaces. Ésta es la parte conducida por el diseño, del TDD. Como parte de la calibración de la prueba, el código debe fallar la prueba significativamente las primeras veces.
 # '''Ejecutar las pruebas automatizadas'''. Si pasan, el programador puede garantizar que el código resuelve los casos de prueba escritos. Si hay fallos, el código no resolvió los casos de prueba.
-# Refactorización y limpieza en el código. Después se vuelven a efectuar los casos de prueba y se observan los resultados.
+# '''Refactorización y limpieza en el código'''. Después se vuelven a efectuar los casos de prueba y se observan los resultados.
 # '''Repetición'''. Después se repetirá el ciclo y se comenzará a agregar las funcionalidades adicionales o a arreglar cualquier error.

← Revisión anterior		Revisión del 19:19 1 sep 2009
Línea 36:		Línea 36:

	[[Category:TDD]]		[[Category:TDD]]
		+	[[Category:Extreme Programming]]

← Revisión anterior		Revisión del 14:39 31 ago 2009
Línea 34:		Línea 34:
	* [http://www.developer.com/java/ent/article.php/3622546 TDD, a portable methodology]		* [http://www.developer.com/java/ent/article.php/3622546 TDD, a portable methodology]
	* [http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd The 3 rules of TDD]		* [http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd The 3 rules of TDD]
		+
		+	[[Category:TDD]]

@@ Línea 29: / Línea 29: @@
 * [[Testing De Aplicaciones]]
 * [[Metodologias De Desarrollo]]
 * [http://es.wikipedia.org/wiki/Tdd TDD en la Wikipedia]
 * [http://www.agiledata.org/essays/tdd.html Introduction to TDD]
 * [http://www.developer.com/java/ent/article.php/3622546 TDD, a portable methodology]
 * [http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd The 3 rules of TDD]

@@ Línea 5: / Línea 5: @@
 TDD permite un diseño más robusto-tanto es así que a menudo se piensa TDD como Diseño manejado por las pruebas (Test Driven Design). En consecuencia, TDD facilita un diseño más mantenible a través de la noción de pruebas. Estas pruebas obligan a reflexionar sobre el comportamiento del código y la forma de garantizar que funciona según lo previsto. La mayoría de las veces, el código influenciado por TDD es relativamente seguro, y sin duda, es bastante simple.
-El código que es seguro y simple es más fácil de cambiar que el código que muestra los rasgos opuestos como la complejidad y la fragilidad. Lo que es más, porque el código escrito con TDD se respaldada en pruebas, cualquier cambio que rompe el código se descubre rápidamente. En esencia, el código escrito con TDD en la mente es más fácil de cambiar y más fácil de arreglar.
+El código que es seguro y simple es más fácil de cambiar que el código que muestra los rasgos opuestos como la complejidad y la fragilidad. Lo que es más, porque el código escrito con TDD se respalda en pruebas, cualquier cambio que rompe el código se descubre rápidamente. En esencia, el código escrito con TDD en la mente es más fácil de cambiar y más fácil de arreglar.
 Pero TDD no trata de que los cambios sean fáciles, al menos no directamente. No, TDD tiene que ver con la velocidad. Cuando los equipos ejecutan TDD consistentemente en sus mentes, las características se producen con mayor rapidez. Características más rápidas significan menos tiempo al mercado. Reducción del período de tiempo de salida al mercado significa mayor posibilidades de obtener más clientes. Lo mejor de todo es que la velocidad de comercialización está respaldado por una red de seguridad de las pruebas que permiten un cambio rápido en la misma cantidad de tiempo (si no más rápido).

@@ Línea 18: / Línea 18: @@
 ==Ciclo de desarrollo TDD==
-# '''Escribir la prueba'''. Para escribir la prueba, el desarrollador debe entender claramente las especificaciones y los requisitos. El diseño del documento deberá cubrir todos los escenarios de prueba y condición de excepciones.
+# '''Escribir la prueba'''. Para escribir la prueba, el desarrollador debe entender claramente las especificaciones y los requisitos. El diseño del documento deberá cubrir todos los escenarios de prueba y condición de [[Excepciones]].
 # '''Escribir el código haciendo que pase la prueba'''. Este paso fuerza al programador a tomar la perspectiva de un cliente considerando el código a través de sus interfaces. Ésta es la parte conducida por el diseño, del TDD. Como parte de la calibración de la prueba, el código debe fallar la prueba significativamente las primeras veces.
 # '''Ejecutar las pruebas automatizadas'''. Si pasan, el programador puede garantizar que el código resuelve los casos de prueba escritos. Si hay fallos, el código no resolvió los casos de prueba.

← Revisión anterior		Revisión del 14:41 31 ago 2008
Línea 1:		Línea 1:
−	Desarrollo guiado por pruebas, o Test Driven ~~development~~ (TDD) es una práctica de programación que involucra otras dos prácticas: Escribir las pruebas primero (Test First Development) y Refactorización (Refactoring). Para escribir las pruebas generalmente se utiliza la [[Prueba Unitaria]] (unit test en inglés).	+	Desarrollo guiado por pruebas, o Test Driven Development (TDD) es una práctica de programación que involucra otras dos prácticas: Escribir las pruebas primero (Test First Development) y Refactorización (Refactoring). Para escribir las pruebas generalmente se utiliza la [[Prueba Unitaria]] (unit test en inglés).

	Primeramente se escribe una prueba y se verifica que las pruebas fallen, luego se implementa el código que haga que la prueba pase satisfactoriamente y seguidamente se refactoriza el código escrito. El propósito del desarrollo guiado por pruebas es lograr un código limpio que funcione (Del inglés: Clean code that works). La idea es que los requerimientos sean traducidos a pruebas, de este modo, cuando las pruebas pasen se garantizará que los requerimientos se hayan implementado correctamente.		Primeramente se escribe una prueba y se verifica que las pruebas fallen, luego se implementa el código que haga que la prueba pase satisfactoriamente y seguidamente se refactoriza el código escrito. El propósito del desarrollo guiado por pruebas es lograr un código limpio que funcione (Del inglés: Clean code that works). La idea es que los requerimientos sean traducidos a pruebas, de este modo, cuando las pruebas pasen se garantizará que los requerimientos se hayan implementado correctamente.

← Revisión anterior		Revisión del 16:53 29 ago 2008
Línea 2:		Línea 2:

	Primeramente se escribe una prueba y se verifica que las pruebas fallen, luego se implementa el código que haga que la prueba pase satisfactoriamente y seguidamente se refactoriza el código escrito. El propósito del desarrollo guiado por pruebas es lograr un código limpio que funcione (Del inglés: Clean code that works). La idea es que los requerimientos sean traducidos a pruebas, de este modo, cuando las pruebas pasen se garantizará que los requerimientos se hayan implementado correctamente.		Primeramente se escribe una prueba y se verifica que las pruebas fallen, luego se implementa el código que haga que la prueba pase satisfactoriamente y seguidamente se refactoriza el código escrito. El propósito del desarrollo guiado por pruebas es lograr un código limpio que funcione (Del inglés: Clean code that works). La idea es que los requerimientos sean traducidos a pruebas, de este modo, cuando las pruebas pasen se garantizará que los requerimientos se hayan implementado correctamente.
		+
		+	TDD permite un diseño más robusto-tanto es así que a menudo se piensa TDD como Diseño manejado por las pruebas (Test Driven Design). En consecuencia, TDD facilita un diseño más mantenible a través de la noción de pruebas. Estas pruebas obligan a reflexionar sobre el comportamiento del código y la forma de garantizar que funciona según lo previsto. La mayoría de las veces, el código influenciado por TDD es relativamente seguro, y sin duda, es bastante simple.
		+
		+	El código que es seguro y simple es más fácil de cambiar que el código que muestra los rasgos opuestos como la complejidad y la fragilidad. Lo que es más, porque el código escrito con TDD se respaldada en pruebas, cualquier cambio que rompe el código se descubre rápidamente. En esencia, el código escrito con TDD en la mente es más fácil de cambiar y más fácil de arreglar.
		+
		+	Pero TDD no trata de que los cambios sean fáciles, al menos no directamente. No, TDD tiene que ver con la velocidad. Cuando los equipos ejecutan TDD consistentemente en sus mentes, las características se producen con mayor rapidez. Características más rápidas significan menos tiempo al mercado. Reducción del período de tiempo de salida al mercado significa mayor posibilidades de obtener más clientes. Lo mejor de todo es que la velocidad de comercialización está respaldado por una red de seguridad de las pruebas que permiten un cambio rápido en la misma cantidad de tiempo (si no más rápido).
		+

	==Las 3 reglas de TDD==		==Las 3 reglas de TDD==

@@ Línea 3: / Línea 3: @@
 Primeramente se escribe una prueba y se verifica que las pruebas fallen, luego se implementa el código que haga que la prueba pase satisfactoriamente y seguidamente se refactoriza el código escrito. El propósito del desarrollo guiado por pruebas es lograr un código limpio que funcione (Del inglés: Clean code that works). La idea es que los requerimientos sean traducidos a pruebas, de este modo, cuando las pruebas pasen se garantizará que los requerimientos se hayan implementado correctamente.
-===Las 3 reglas de TDD===
+==Las 3 reglas de TDD==
 La práctica de TDD puede resumirse en 3 simples reglas:
@@ Línea 10: / Línea 10: @@
 # No se puede escribir más código productivo del estrictamente necesario para hacer pasar un test.
+==Ciclo de desarrollo TDD==
 # Escribir la prueba. Para escribir la prueba, el desarrollador debe entender claramente las especificaciones y los requisitos. El diseño del documento deberá cubrir todos los escenarios de prueba y condición de excepciones.
 # Escribir el código haciendo que pase la prueba. Este paso fuerza al programador a tomar la perspectiva de un cliente considerando el código a través de sus interfaces. Ésta es la parte conducida por el diseño, del TDD. Como parte de la calibración de la prueba, el código debe fallar la prueba significativamente las primeras veces.
@@ Línea 19: / Línea 17: @@
 # Repetición: Después se repetirá el ciclo y se comenzará a agregar las funcionalidades adicionales o a arreglar cualquier error.
-Este ciclo se suele abreviar como __rojo-verde-refactor__ (haciendo referencia a fallar un test, hacerlo pasar, y hacer un refactor).
+Este ciclo se suele abreviar como '''rojo-verde-refactor''' (haciendo referencia a fallar un test, hacerlo pasar, y hacer un refactor).
 ==Ver también==
 * [[Testing De Aplicaciones]]
 * [[Metodologias De Desarrollo]]
 * [http://es.wikipedia.org/wiki/Tdd TDD en la Wikipedia]
 * [http://www.agiledata.org/essays/tdd.html Introduction to TDD]
 * [http://www.developer.com/java/ent/article.php/3622546 TDD, a portable methodology]
 * [http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd The 3 rules of TDD]