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.
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.
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.
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.
Muy interesante!!!!!!!! Gracias por compartirlo!
Muy bueno, pero no es una COPIA exacta a el post de El Bruno del día 21 (hace ya tres días). Es que has copiado TODO… por lomenos creo que deberías mencionarlo.
http://geeks.ms/blogs/elbruno/archive/2009/03/21/vsts2010-data-driven-coded-ui-tests-genial.aspx
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
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 🙂
Hola!
Bruno te pagaré esa cerveza por el agravio 🙂
Un saludo,
No es una copia, es normal que las temáticas coincidan porque estamos hablando mucha gente de las mismas cosas…
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
Hola Juliana,
No he entendido muy bien la pregunta? Quieres saber cómo hacer pruebas de un módulo que recibe XML y devuelve como salida XML?
Hola, gracias, si, me refiero a eso, nos conectamos a un webservices y existe un xml de entrada y uno de salida, como se trabaja esto en team system? me cuentas
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?
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