Test Driven Development
Existen algunos enfoques interesantes como el desarrollo dirigido por pruebas, o TDD (Test-driven Development), que nos llevan a una nueva relación testing-desarrollo. Uno de los principios fundamentales de esta estrategia es que el desarrollador escribe primero los tests y luego el código. Uno de los aspectos interesantes de este enfoque es que el escribir primero las pruebas hace que el desarrollador tenga un acabado conocimiento de los requerimientos funcionales antes de comenzar a escribir la primera línea de código.
A grandes rasgos, estos son los pasos que hay que seguir para aplicar el desarrollo dirigido por pruebas:
1. Agregar un test
2. Ejecutar todos los test y ver que el nuevo falla (obviamente porque la rutina que testea no ha sido descrita todavía)
3. Escribir el código
4. Ejecutar los test y corregir el código hasta que pasen los tests
5. Hacer refactoring para mejorar el código, la ejecución de los test completos asegura que no “rompemos”nada durante este proceso
Luego de que el código es aceptado, porque pasó correctamente todos los tests, comienza la etapa de refactoring que permite optimizar, organizar y mejorar. La ejecución de todos los test asegura que no hemos “roto” nada durante este paso.
Testing con Visual Studio
Ahora veamos con un ejemplo simple las capacidades que posee Visual Studio Team System (VSTS) para cubrir nuestras necesidades de testing. Supongamos que tenemos una clase Cálculo que posee algunos métodos para realizar cálculos matemáticos y queremos crear una serie de tests para verificar el correcto funcionamiento de éstos. VSTS incorpora un nuevo tipo de proyecto destinado a la labor de testing. En las figuras 1 y 2 podemos ver cómo agregar uno para nuestra clase Cálculo.
Figura 1. Creación de un proyecto de testing
Figura 2. Creación de un proyecto para testing unitario
La clase Cálculo posee un método Factorial que realiza el cómputo del factorial de un número dado. El código del método factorial es el indicado en el ejemplo 1, esta es la primera aproximación, y contiene algunos errores (cualquier programador que mire atentamente el código podrá darse cuenta). Para crear un método de test unitario para el mismo sólo es necesario realizar click derecho sobre el método y seleccionar la opción “Create Unit Test”.
public class Calculo
{
public long Factorial(int x)
{
if (x < 0)
{
throw new ArgumentOutOfRangeException”x”, x,
“El parámetro x no puede ser negativo”);
}
long factorial = 1;
for (int i = 1; i <= x; i++)
{
factorial *= i;
}
return x;
}
}
Ejemplo 1. Método Factorial primera versión
Figura 3. Creación de un test para el método
El método de test que hemos creado es el especificado en el ejemplo 2. Éste método tiene un arreglo que contiene un conjunto de pares de prueba que es recorrido uno por uno para probar cada caso particular. Posteriormente utilizamos el método Assert.AreEqual() para comparar los valores esperados con los realmente obtenidos y comunicar a Visual Studio Team System de lo ocurrido con las pruebas.
/// <summary>
///Prueba del metodo Factorial
///</summary>
[TestMethod()]
[Owner(“Gustavo Bonansea”)]
[Description(“Prueba del metodo Factorial”)]
public void FactorialTest()
{
long[,] conjuntoPruebas = new long[8,2]
{
{0 , 1},
{1 , 1},
{2 , 2},
{3 , 6},
{4 , 24},
{8 , 40320},
{10, 3628800},
{20, 2432902008176640000}
};
long esperado;
long real;
int x;
for (int i = 0; i <= conjuntoPruebas.GetLength(0); i++ )
{
x = (int) conjuntoPruebas[i, 0];
esperado = conjuntoPruebas[i, 1];
real = calculoClass.Factorial(x);
Assert.AreEqual(esperado, real, string.Format(
“El método factorial ha fallado para el par de prueba ({0}, {1})”, x, esperado));
}
}
Ejemplo 2. Código del método de prueba
Luego de la primera ejecución del test obtenemos un resultado negativo indicando que ha fallado para el par de prueba (0,1).
como se ve en la figura 4.
Figura 4. Test fallido
Esto es debido a que la función está devolviendo el valor de x en vez de la variable factorial que es en la cual estamos acumulando el cálculo. Si corregimos este desperfecto el test será satisfactoriamente completado.
Code Coverage
Una funcionalidad muy interesante que podemos utilizar es el “Code Coverage”, la cual analiza el código que ha sido efectivamente ejecutado, indicando qué porcentaje del código no ha sido cubierto por el conjunto de pruebas utilizado. En la figura 5 podemos observar que el código pintado de rojo no ha sido ejecutado nunca durante las pruebas, lo que indica que el conjunto de pruebas no es lo suficientemente amplio para cubrir todas las posibilidades contempladas por la función.
Figura 5. Resultado del Code Coverage
Hemos visto con un breve ejemplo cómo crear y ejecutar un test unitario para una función y hemos revisado el resultado del Code Coverage del mismo para verificar el nivel de cobertura del test. Pero esto es solo una pequeña parte de las funcionalidades que nos brinda VSTS en su versión para Testers. Abajo nombraremos algunas características adicionales.
Test manuales
No todos los tests son automatizados, si necesitamos dentro de nuestro proyecto realizar pruebas manuales; VSTS incluye plantillas para facilitar esta tarea y luego provee de asistencia durante la ejecución y registración de los resultados de las mismas.
Test genéricos
VSTS utiliza este tipo de test para brindar la posibilidad de incluir herramientas externas de testing que no estén totalmente integradas con el IDE.
Test Web
Permite automatizar el testing de sistemas basados en web, grabando las acciones realizadas sobre una sesión de Internet Explorer en scripts que luego pueden ser editados. Permite el control de la simulación con respecto al tipo y cantidad de conexiones, el tipo de browser y la posibilidad de emular el tiempo de “pensamiento” del usuario, es decir que utiliza los tiempos reales que se tomaría un humano para cada acción. Pueden definirse luego una serie de reglas de validación para corroborar la validez del valor de los controles en la respuesta a cada petición.
Test de carga
Tiene por objetivo verificar la respuesta de un sistema ante su uso intensivo, para identificar problemas de performance y escalabilidad, e identificar posibles cuellos de botella.
Acerca del autor
Gustavo Bonansea tiene más de 8 años de experiencia en el mercado argentino de TI. En los últimos tres, ha podido contribuir como Software Engineer en el éxito de Pectra BPM Studio Framework, producto merecedor en 2004 y 2005 del Excellence in Workflow Global Award. Su pasión por ir más allá de los límites de la tecnología la desarrolló en los años que fue miembro y coordinador de varios grupos de investigación en la Universidad, centrándose en tecnologías relacionadas a Business Intelligence, especialmente en técnicas estadísticas y de inteligencia artificial aplicadas a la minería de datos. Actualmente se desempeña como Director de Proyectos de la empresa Raona Argentina.
- Log in to post comments