Diferencia entre revisiones de «Test Driven Development»
De Dos Ideas.
(→Ver también) |
|||
| 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. | 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== | |
La práctica de TDD puede resumirse en 3 simples reglas: | 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. | # 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 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. | # 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. | # 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 | + | 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]] | * [[Testing De Aplicaciones]] | ||
* [[Metodologias De Desarrollo]] | * [[Metodologias De Desarrollo]] | ||
| − | |||
| − | |||
* [http://es.wikipedia.org/wiki/Tdd TDD en la Wikipedia] | * [http://es.wikipedia.org/wiki/Tdd TDD en la Wikipedia] | ||
* [http://www.agiledata.org/essays/tdd.html Introduction to TDD] | * [http://www.agiledata.org/essays/tdd.html Introduction to TDD] | ||
* [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] | ||
Revisión del 13:38 27 jul 2008
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.
Las 3 reglas de TDD
La práctica de TDD puede resumirse en 3 simples reglas:
- No se puede escribir código productivo, a menos que sea para hacer pasar un test fallido.
- No se puede escribir más que lo necesario para que falle un test unitario; los errores de compilación se consideran fallos.
- 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.
- 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.
- 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).
