Semana 3 Desarrollo Guiado por Pruebas Automatizacin de Pruebas

Desarrollo guiado por pruebas

(TDD: Test Driven Development)
Cuando creamos una aplicacin, es muy importante probar el cdigo. Se puede
hacer de varias formas una de ellas consiste en ejecutar muchas veces la
aplicacin cuando est acabada, pero especialmente mientras se encuentra en
desarrollo, probar y probar mucho, !Muchas veces!, una y otra vez. Otra solucin
ms eficiente (y menos aburrida), consiste en hacer test automticos de prueba,
que se ejecuten automticamente cada vez que compilamos. De esta forma, sin
que nos cause ningn trastorno, nuestra aplicacin se estar probando sola una y
otra vez.

La mejor forma de llevar a la prctica estos test automticos y probar nuestro

cdigo, consiste en hacer primero los test. NO HACEMOS CDIGO y luego el test
que lo prueba, sino que primero pensamos una cosa concreta que tiene que hacer
nuestra aplicacin, luego hacemos el test que prueba que nuestra aplicacin hace
eso y despus (y slo despus de hacer el test), hacemos el cdigo necesario
para que ese test pase correctamente.

Y siguiendo esta filosofa, nace precisamente TDD (Test Driven Development).

Una metodologa en la que primero se hace un test y luego el cdigo necesario
para que el test pase. No se hace nada de cdigo si no falla algn test, por lo que
primero debemos hacer el test que falle.

Los tres pasos de TDD

En TDD deben seguirse estos tres pasos y en este orden:

1. Hacer un test automtico de prueba, ejecutarlo y ver que falla.

2. Hacer el cdigo mnimo imprescindible para que el test que acabamos de
escribir pase.
3. Arreglar el cdigo, sobre todo, para evitar cosas duplicadas en el mismo.
Comprobar que los test sigue pasando correctamente despus de haber
arreglado el cdigo.

Estos tres pasos deben repetirse una y otra vez hasta que la aplicacin est
terminada.

1
Semana 3 Desarrollo Guiado por Pruebas Automatizacin de Pruebas

Test Automticos de Prueba

Cuando una sola persona hace un programa ms o menos pequeo, normalmente
puede ir codificando su programa poco a poco, compilar de vez en cuando,
ejecutarlo y ver si lo que est haciendo funciona. El proceso de probar a mano
puede llevarle un tiempo razonable y el programa puede, al final, quedar
perfectamente hecho. De hecho, es una de las formas ms divertidas de
programar, ir haciendo cosas y ver rpidamente si funcionan o no.

Sin embargo, si hablamos de programas ms grandes y de varios desarrolladores

trabajando simultneamente en varias partes de l, el proceso de pruebas cobra
especial importancia. Es posible que un desarrollador, sin querer, haga algn
cambio que produzca fallos en el funcionamiento del cdigo de otro desarrollador.
Es ms, un mismo desarrollador, segn van pasando los das y va codificando,
puede ir olvidando los detalles del cdigo que desarroll unas semanas antes y
nuevamente, sin querer, ser el mismo el que estropee lo que haba hecho al ir
aadiendo nueva funcionalidad.

Al ser el programa grande, las pruebas manuales deben ser frecuentes, para
comprobar que segn pasa el tiempo, lo que estaba funcionando, sigue
funcionando, adems de comprobar que lo que acabamos de hacer tambin
funciona. Pero al mismo tiempo, al ser el programa grande, esas pruebas
manuales llevan cada vez ms tiempo, ya que cada vez hay ms cosas que
probar.

Sera maravilloso si hubiera algo que probar nuestro programa de forma

automtica y con frecuencia. Si cada vez que hacemos cambios o aadimos
cdigo le decimos a ese algo que prueba nuestro programa y nos
despreocupamos del tema, nos ahorraramos mucho tiempo de prueba.

Afortunadamente, existe ese algo. Podemos hacer un programa que se encargue

de probar nuestro programa. Ese programa de pruebas debera ser fcil de lanzar,
deberamos lanzarlo con frecuencia, no debera requerir ninguna intervencin por
nuestra parte y no debera darnos unos resultados que tengamos que analizar.
nicamente debemos lanzarlo y el slo debe decirnos "Todas las pruebas han ido
bien". O si no hemos tenido suerte, "Han fallado estas pruebas en estos sitios".

Obviamente, hacer estos programas de prueba es ms trabajo, pero cuando ms

grande y complejo es el proyecto en el que estamos involucrados, ms tiempo
vamos a ahorrar a la larga.

2
Semana 3 Desarrollo Guiado por Pruebas Automatizacin de Pruebas

Las ventajas de tener unos buenos programas de prueba son:

1. Al ser la prueba automtica, nos dar menos pereza lanzarla con

frecuencia. De hecho, lo ideal es hacer un trozo de cdigo y pasar las
pruebas. Si hemos fastidiado algo, sabremos que el trozo de cdigo que
acabamos de tocar es el que ha introducido el fallo. Si la prueba es larga y
manual, seguramente probaremos con menos frecuencia. Si algo se
estropea, quizs tengamos que buscar el fallo en el cdigo que hemos
hecho durante toda la semana.
2. Tener las pruebas automticas nos quita el miedo a tocar el cdigo que ya
est funcionando. A veces vemos cdigo que est funcionando pero que no
est todo lo bien hecho que debiera. Otras veces, tenemos que arreglar un
poco ese cdigo para poder reutilizarlo en una nueva funcionalidad que
queremos dar a nuestro programa. Si no tenemos una forma fcil de ver
que ese cdigo sigue funcionando despus de tocarlo, igual no nos
decidimos a tocarlo.
3. Una prueba automtica que falla nos da ms informacin que una prueba
manual que detecta un fallo. Si una prueba automtica falla, nos dice
exactamente qu mtodo del cdigo no hace lo que se esperaba de l. Si
una prueba manual encuentra un fallo, slo sabemos que algo en cualquier
parte del cdigo no est bien.

Las pruebas automticas ayudan mucho, pero tampoco garantizan nada al 100%.
Nunca nos quitaremos del todo la necesidad de hacer pruebas manuales, pero
incluso haciendo pruebas manuales, algunos errores se colarn y saldrn ms
adelante... o nunca. Las pruebas automticas son simplemente una primera
actividad que nos ahorrar tiempo al detectar automticamente un porcentaje alto
de los errores en el cdigo.

Actualmente, en cualquier proyecto de software mnimamente serio, es

impensable no realizar test automticos de prueba, ya que el ahorro de tiempo y la
mejora del software al hacer estos test est de sobra probada.

3
Semana 3 Desarrollo Guiado por Pruebas Automatizacin de Pruebas

Cmo escribir una prueba (test, test case o caso de prueba)?

En primer lugar pensar en lo que desea probar. Hay por lo menos tres cosas
tenemos que escribir la prueba de: positivo, negativo y de excepcin. Hay que
pensar en la forma en la cual se debe desarrollar cierta tarea dentro de nuestro
programa, es decir, pensar en el positivo, lo que debe hacer
correctamente asumiendo todas las cosas es lo ideal. Despus piensa en lo
negativo, es decir, lo que podra salir mal y cmo debe comportarse el cdigo. La
excepcin es pensar en la posibilidad de secuencia alternativa de eventos que
podra suceder y cmo debe comportarse el cdigo para dar cabida a aquellos.

Dnde se debe escribir la prueba?

El cdigo de prueba no debe estar dentro del mimo mtodo o clase ya sean
pblicos, privados o protegidos, pero si debe ser parte del mismo proyecto. Sea
cual sea la tecnologa de desarrollo con la que estemos trabajando, java .NET, C#,
C++. En el caso de java debe existir un paquete que contenga el cdigo de
prueba.

Actividad Contesta las siguientes preguntas en tu cuaderno de notas, justificando

cada una de tus respuestas

1. Cul es el objetivo del Desarrollo Guiado por Pruebas?

2. Qu significa TDD?
3. Qu ventaja tiene aplicar un desarrollo guiado por pruebas?
4. Qu es una prueba automatizada?
5. Si se te pide realizar un programa que realice operaciones matemticas
tales como el factorial de un nmero x, multiplicacin, divisin etc, que es lo
primero que realizas?
6. En que consiste el ltimo paso del TDD?
7. Qu consecuencias traer el cambiar parte del cdigo?
8. Por qu las pruebas pueden parecer tediosas?
9. Cules son los puntos minimos requeridos para realizar un caso de
prueba?
10. Donde debe quedar documentado los resultados de los casos de prueba?
11. Es conveniente que el cdigo de produccin este junto con el cdigo de
prueba?
12. Realiza y explica un diagrama donde se muestren los pasos para aplicar el
TDD en un proyecto de software.