Pruebas unitarias: Orígenes de datos para alimentar las pruebas

En algunas ocasiones, para poder probar de forma completa un módulo es necesario probar muchas variantes en los parámetros de entrada.

Por ejemplo, si tenemos nuestra ya famoso método Sumar, con podría interesar probar el método con diferentes parámetros de entrada, para comprobar que realmente suma bien en todas las situaciones.

Una primera aproximación podría ser escribir tantas pruebas como necesitemos, cambiando en cada prueba los parámetros de entrada. Una solución poco adecuada.

La solución, más adecuada, cuando las N pruebas sólo cambian en los datos de entrada, es usar la característica que nos ofrece Visual Studio para generar una única prueba y cargar los diferentes escenarios de datos desde un origen de datos.

El proceso para configurar un origen de datos para una prueba es muy sencillo. Desde la ventana que muestra la lista de pruebas unitarias de la solución, seleccionaremos la prueba unitaria que nos interese.

Una vez seleccionada podremos ver sus propiedades. A través de la propiedad “Data Connection String” podremos especificar el origen de datos.

image

Si pinchamos sobre esta opción nos aparecerá un asistente que nos guiará paso a paso para especificar el origen de datos, que puede ser una base de datos, un fichero CSV o un fichero XML.

image

Seleccionamos un fichero CSV que tiene tres valores separados por comas. Los dos primeros son los valores a sumar, siendo el tercero el resultado esperado.

image

Una vez hecha esta operación, tendremos que modificar nuestra prueba para que sea capaz de usar el origen que acabamos de añadir.

A través de la variable de clase TestContext que posee la clase de pruebas podremos acceder a los datos, usando la propiedad DataRow.

La prueba unitaria queda de la siguiente manera:

[DataSource("Microsoft.VisualStudio.TestTools.DataSource.CSV", 
    "|DataDirectory|\testdata.csv", "testdata#csv", DataAccessMethod.Sequential), 
    DeploymentItem("TestProject1\testdata.csv"), TestMethod()]
public void SumarTest()
{
    Service1 target = new Service1();
    int a = (int)this.TestContext.DataRow[0];
    int b = (int)this.TestContext.DataRow[1];
    int expected = (int)this.TestContext.DataRow[2];
    int actual;
    actual = target.Sumar(a, b);
    Assert.AreEqual(expected, actual);
}

Fijaros en los atributos DataSource y DeploymentItem. Estos dos atributos se han añadido al configurar el origen de datos.

El atributo DataSource indica el origen de datos que se empleará en la prueba, así como la forma de acceder al mismo.

El atributo DeployementItem permite especificar ficheros adicionales que se incluirán entre los ficheros que se usarán para la prueba. En este caso se indica que se va a incluir el fichero testdata.csv, que es el fichero que contiene todos los valores posibles que queremos probar como parámetros de entrada.

El resultado que obtenemos es como si la prueba la ejecutásemos tantas veces como número de registros tenga el origen de datos.

image

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.

11 comentarios en “Pruebas unitarias: Orígenes de datos para alimentar las pruebas”

  1. Ibon genial el post …

    Juan, pues lo de Ibon no es plagio (aunque gracias por tenerlo en cuenta, le pediré una cerveza a cambio :D) Ibon viene escribiendo de Unit Tests desde hace tiempo y en algún momento tenían que caer las DDT.

    Las Data Driven Tests existen desde hace mucho (VS2005) y son extremadamente útiles en algunas ocasiones. En MSDN (donde sino) es posible encontrar mucha mas información http://msdn.microsoft.com/en-us/library/ms182527(VS.80).aspx, http://msdn.microsoft.com/en-us/library/ms182528(VS.80).aspx.

    Saludos

  2. Pues sí que es muy similar al del Bruno, pero te puedo asegurar que no es una copia.

    El del Bruno habla sobre VStudio 2010 y cómo usar los origes de datos para completar las pruebas de un post anterior que hablaba sobre pruebas en interfaces windows.

    Y seguro que no es una copia tb, porque este post lleva escrito más de 3 días, aunque se haya publicado hoy 🙂

  3. Hola, si me pueden por favor ayudar con esta inquietud:

    Tengo lo siguiente: Un motor que integra el contenido del sistema de un proveedor con el de otros proveedores. Los portales de venta de viajes – consolidadores, sistemas de reservas corporativos o agencias de viajes online – pueden acceder a este contenido a través de una interfaz única y reducir sustancialmente los costes de mantenimiento y desarrollo de conexiones desde sus propios portales.

    La inquietud es: me están enviando archivos XML con datos de entrada y salida,no existe una interfaz de pruebas, en team system como puedo trabajar esto? es decir, para hacer pruebas unitarias y luego correr los casos de prueba?

    Te agradezco

  4. Hola,

    No sé si estás familiarizada con el framework de VStudio pero si no lo estás, creo que podría venirte bien echar un ojo a una serie de post que he escrito sobre el tema y que explican paso a paso cómo funciona este framework:
    http://geeks.ms/blogs/ilanda/archive/2009/06/16/pruebas-unitarias-resumiendo.aspx

    Probar un método que recibe un XML y genera otra, es similar a probar cualquier otro método, como el método Sumar que veía este este post:http://geeks.ms/blogs/ilanda/archive/2009/03/04/pruebas-unitarias-manos-a-la-obra-i.aspx

    Te aclaro algo con esto?

  5. Hola, gracias, bueno mas o menos entiendo, me explico otra vez:
    En team system porque modulo, por cual opción puedo conectarme a una dirección WSDL (no local) que invoque los servicios web de una aplicación y yo tome un archivo xml de entrada, lo cargue y lo procese y obtenga una respuesta, adicionalmente pueda cambiar parametros, inicialmente con pruebas manuales y a mediano plazo automatizadas.
    Me cuentas y te agradezco

Responder a aarroyo Cancelar respuesta

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