Pruebas unitarias: Manos a la obra ( I )
Hasta ahora he estado hablando de las pruebas unitarias desde un aspecto puramente teórico.
He hablado sobre las características una buena unitaria, de sus beneficios y de los mitos que rodean hasta buena práctica.
Y aunque todavía intentaré escribir algo más en el aspecto teórico ha llegado el momento de ver algo más práctico.
En los próximos post intentaré aportar mi granito de arena y explicar de una manera sencilla las características que viene con Team System para realizar pruebas unitarias desde un aspecto más práctico.
Como muchos ya sabréis Visual Studio nos proporciona un sistema sencillo para poder crear nuestras pruebas unitarias. Nos facilita la creación de los proyectos de pruebas y nos genera la estructura básica que tiene que tener la prueba.
Supondremos que tenemos una clase que tiene un método Suma. Este método, recibe como parámetro dos valores enteros y devuelve la suma ambos. Sí, el ejemplo es un poco tonto pero la idea es dar a conocer la herramienta, tiempo habrá para complicar el ejemplo.
public int Sumar(int a, int b )
{
return a + b;
}
Una vez implementado el método necesitamos probarlo. Para ello creamos nueva primera prueba unitaria. Si seleccionamos el método Sumar, en el menú contextual tendremos la opción de crear una prueba unitaria.
La prueba la podremos crear en un nuevo proyecto de test o en uno ya existente. Como es nuestra primera prueba, lógicamente, lo incluiremos en un nuevo proyecto de test.
Mi recomendación es crear al menos un proyecto de Test por cada proyecto que tengas en tu aplicación, en lugar de crear un único proyecto de test que englobe todos los las pruebas de tu aplicación.
El nuevo proyecto que se crea es un proyecto normal y corriente. La única peculiaridad que tiene una referencia de Microsoft.VisualStudio.QualityTools.UnitTestFramework.
Ten en cuenta, que con este paso no se crea la prueba, sólo la estructura de proyectos, clases y métodos. Es labor de desarrollador, en base a las especificaciones del módulo, el desarrollo de las pruebas. Es importante que el desarrollador realice tantas pruebas como sea necesario para cubrir al máximo la funcionalidad del módulo que se prueba.
Fijaros en el código del método de prueba que tanto la clase como el método son clases y métodos normales, con la única peculiaridad que el método está decorado con el atributo TestMethod.
///A test for Sumar
///</summary>
[TestMethod()]
public void SumarTest()
{
ClaseEjemplo target = new ClaseEjemplo(); // TODO: Initialize to an appropriate value
int a = 0; // TODO: Initialize to an appropriate value
int b = 0; // TODO: Initialize to an appropriate value
int expected = 0; // TODO: Initialize to an appropriate value
int actual;
actual = target.Sumar(a, b);
Assert.AreEqual(expected, actual);
Assert.Inconclusive("Verify the correctness of this test method.");
}
Cuando hemos creado el proyecto de Test, en la solución han aparecido dos nuevos ficheros: Sample.vsmdi y LocalTestRun.testrunconfig.
Si hacemos doble-click sobre el archivo vsmdi podremos acceder al editor de la lista de pruebas unitarias. Desde aquí podremos ver, lanzar o depurar todos las pruebas unitarias que contiene la solución. Y digo que contiene la solución, porque este fichero es común para todos los proyectos de Test de la solución. Si éste contiene 2 proyectos de Test, desde la lista de pruebas unitarias veremos todas las pruebas de los dos proyectos.
El fichero LocalTestRun.testrunconfig lo que nos va a permitir es configurar algunos aspectos relacionados con la ejecución de las pruebas, como activar el análisis de la cobertura de código.
Una vez que tenemos la estructura de nuestro método de prueba tendremos que implementar la prueba.
La idea es muy sencilla. Si pasamos 1 y 2 en los parámetros de entrada el método sumar nos tiene que devolver 3. Es decir, sabiendo los parámetros de entrada y lo que hace el método que estamos probando, sabremos lo que tiene que devolver.
El objetivo de la prueba es comprobar que el método Sumar hace exactamente lo que se espera de él. Si el método Sumar en lugar de 3 devolviese 7, porque se ha equivocado al sumar, la prueba unitaria fallaría.
Una vez hecha prueba recuerda eliminar la sentencia Assert.Inconclusive.Esta sentencia se incluye cuando se crea la prueba e indica que el resultado de la prueba no es concluyente. De esta manera se marcan las pruebas que no están implementados.
[TestMethod()]
public void SumarTest()
{
ClaseEjemplo target = new ClaseEjemplo();
int a = 1;
int b = 2;
int expected = 3;
int actual;
actual = target.Sumar(a, b);
Assert.AreEqual(expected, actual);
}
Una vez, hecha la prueba sólo tenemos que ejecutarla. Desde la ventana de lista de pruebas podemos ejecutar todas las pruebas o sólo aquellas que seleccionemos. En la parte inferior, en la ventana de resultados de la prueba veremos el resultado de la ejecución de los mismos.
Bueno, por el momento lo dejamos aquí. En el siguiente post seguiremos viendo algunos aspectos básicos del Framework de pruebas unitarias, como son la cobertura de código o el uso de atributos.