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.

image

image

El nuevo proyecto que se crea es un proyecto normal y corriente. La única peculiaridad que tiene una referencia de Microsoft.VisualStudio.QualityTools.UnitTestFramework.

image

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.

image

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.

image

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.

image

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.

Ibon Landa

bon Landa lleva más de 15 años dedicado al desarrollo de software. Durante este tiempo ha trabajado en diferentes empresas en las cuáles ha podido trabajar en diferentes entornos y tecnologías. Actualmente está focalizado principalmente en tareas de desarrollo, arquitectura, en las herramientas del ciclo de vida y en todo lo relacionado con la plataforma de Cloud Computing Microsoft Azure, área en el que ha sido reconocido como MVP. Participa de forma activa en la comunidad, escribiendo su blog, manteniendo un portal sobre Microsoft Azure y colaborando con Microsoft y grupos de usuarios en eventos de formación, talleres y giras de producto.

7 comentarios en “Pruebas unitarias: Manos a la obra ( I )”

  1. Hola Ibon
    Quiero incursionar en las pruebas unitarias.
    Te cuento que soy tester, y la verdad que no tengo muchos conocimientos de desarrollo, las pruebas siempre fueron manuales y no necesitaba conocer código.
    Estoy tratando de hacer el ejemplo de la Suma pero no me sale, seguramente tengo mal la parte del desarrollo.
    Quería pedirte si me podrías pasar el código exacto de la suma, espero que me puedas ayudar
    Gracias!!!
    Fernando

  2. Hola Ibon, requiero que me ayudes porfa, soy nueva utilizando el modulo de pruebas de team system y requiero lo siguiente paso a paso:
    es un webservices, entonces solo nos dan una dirección web del ambiente de pruebas a donde conectarnos y nos envian un archivo xml de request (requerimiento) y un xml de response (respuesta)

    Mi inquietud es: Ya me instalaron el test edition que es el modulo de pruebas de team system, como podria generar una prueba que cargue el request y vea el resultado, osea el response con los mismos datos que me enviaron.

    Esto se trabaja como crear una prueba unitaria? ó creando una prueba web tambien funciona?

    Me cuentas y gracias

  3. Hola!

    Pues se puede hacer de las dos maneras, creando una prueba unitaria o una prueba web.

    Si no hubieras oido hablar nunca de Team System, seguramente la opción que cogerías es hacer un pequeño programa, por ejemplo uno de consola.

    Una vez creado el programa, le puedes añadir a éste una referencia web al servicio para de esta manera poder invocarlo…y si lo puedes invocar, ya puedes mandarle el XML de entrada y comprobar cómo es el de salida….

    Pues si lo haces con pruebas unitarias, es lo mismo; crear un proyecto de Test, crear una nueva unitaria, añadir la referencia web y hacer todas las llamadas que necesites para comprobar que la funcionalidad es la correcta.

    Con una prueba web se podría conseguir algo similar; con las pruebas web lo que se hace es enviar peticiones HTTP a un consola web o a un servicio, pudiendo añadir comprobaciones en los resultados que devuelve. En este caso que comentas utilizaría la primera opción.

    Un saludo,

  4. Hola.

    Yo he seguido el ejemplo y la verdad con esto ya he aprendido lo basico, espero pder hacerlo en lo que necesito.
    Yo voy a trabajar en un par de dias en ASP:NET MVC3 y tengo que hacer pruebas unitarias de metodos que se vayan a insertar en la base de datos.
    Si alguno tiene algun ejemplo practico por favor hagamelo saber, yo simepre estoy visitando esta pagina gracias.

    Saludos, Jhonny Nina Veizaga.
    Correo: jhonnyninascrum@gmail.com

Responder a jhonnyninascrum Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *