Diferencia entre revisiones de «Test Driven Development»
(→Ciclo de desarrollo TDD) |
|||
| Línea 11: | Línea 11: | ||
==Ciclo de desarrollo TDD== | ==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. |
| − | # 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 | + | # '''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). | ||
Revisión del 13:39 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).
