Diferencia entre revisiones de «Test Driven Development»
(→Ciclo de desarrollo TDD) |
|||
| (No se muestra una edición intermedia de otro usuario) | |||
| 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. | # '''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. | # '''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. | # '''Repetición'''. Después se repetirá el ciclo y se comenzará a agregar las funcionalidades adicionales o a arreglar cualquier error. | ||
| Línea 36: | Línea 36: | ||
[[Category:TDD]] | [[Category:TDD]] | ||
| + | [[Category:Extreme Programming]] | ||
Revisión actual del 19:15 10 mar 2010
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.
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 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).
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).
