¿Le resultó útil esta página?
Sus comentarios sobre este contenido son muy importantes. Háganos saber su opinión.
¿Tiene comentarios adicionales?
Caracteres restantes: 1500
Exportar (0) Imprimir
Expandir todo
Expandir Minimizar

Test Driven Development con Visual Studio Team System

Por Francisco Lomas

Contenido

 1. Introducción
 2. Conceptos Clave
 3. Escenario de Ejemplo
 4. Creando y configurando las pruebas
 5. Ejecución y Análisis de las Pruebas
 6. Conclusión

1. Introducción

En estos días, el Desarrollo de Software se ha convertido en una tarea cada vez más difícil; muchos factores intervienen para poder afirmar esto, entre ellos, el alto grado de competitividad que ha introducido la globalización a nuestros países, logrando que compitamos con los mejores desarrolladores del mundo, así como la increíble oferta de productos de muy alta calidad, entre muchos otros que logran que la vida continúe como la hemos conocido, desde tiempos ancestrales: un fascinante torneo en el cual el premio es la supervivencia.

¿A qué viene esta introducción? En todos los contextos en los que nos movemos día tras día, es necesario que todo lo que realizamos se distinga por la calidad que pueda brindar; aún con más razón en el contexto del desarrollo de software, ya que normalmente el software que hoy producimos tiene una misión critica: mejorar un proceso critico dentro de una organización.

Para cumplir esta misión es imperativo que nuestros esfuerzos estén debidamente coordinados a fin de generar un producto de alta calidad, lo que brindará un valor agregado y mayor productividad a la organización, así como alta confiabilidad. Esto permitirá que quienes van a ser los usuarios finales del producto, tanto como la organización, sientan seguridad y confianza utilizando el producto que desarrollamos.

Todo esto nos lleva al nivel netamente operativo de los equipos de desarrollo, enfocándonos especialmente en los programadores, de la calidad con la que el código esté escrito dependerá cómo el producto sea visto por nuestros clientes y, en muchos casos, como sea visto por el mundo entero.

El Desarrollo basado en Pruebas o Test Driven Development es una práctica que se debe incorporar en cada equipo de desarrollo de software, así como se debe procurar introducir como cultura en la educación formal de los miembros del equipo; esta consiste en estructurar pruebas de varios tipos para cada una de las piezas que componen nuestra solución, así como para comprobar que nuestra solución funciona completa, así mismo si ésta funciona integrada con otras soluciones, las cuales son necesarias para el desarrollo normal de las actividades de la organización para quien producimos nuestra solución.

Esta práctica sin embargo no es muy generalizada por muchas razones, entre ellas, la falta de herramientas de fácil uso y completa integración con sus entornos de desarrollo, así como la incomodidad que produce realizar pruebas que realicen su trabajo efectivamente en nuestro código. Estas dificultades y muchas otras más son muy bien manejadas por Visual Studio Team System; el que nos provee más de una herramienta que nos proporciona una gran facilidad para poner en práctica el Test Driven Development en forma efectiva.

2. Conceptos Clave

Antes de comenzar, debemos conocer algunos conceptos y términos que serán frecuentemente utilizados en adelante para poder comprender y aplicar correctamente el Test Driven Development:

Pruebas Unitarias

Son pruebas que se enfocan en verificar una cierta porción de código, como por ejemplo una función, pasando los parámetros adecuados y analizando si el resultado de esta operación es el esperado.

Pruebas de Carga

Son pruebas orientadas a analizar el rendimiento de la solución o parte de ella en condiciones predefinidas en cuanto a uso, por ejemplo, cómo se comporta una aplicación Web con un número simulado de conexiones, realizando una cierta secuencia.

Pruebas de Integración

Son pruebas que se realizan para comprobar el funcionamiento entre componentes de nuestra solución, entendiéndose como componentes a unidades que realizan una cierta tarea a un nivel de resultados más globales, por ejemplo un Servicio Web que nos devuelve datos cruciales para nuestro Sitio Web de Comercio.

Pruebas Manuales

Son pruebas que, a diferencia de las anteriores, tienen que ser realizadas por un ser humano, normalmente los miembros del grupo de Aseguramiento de Calidad.

Cubrimiento de Código
No es más que la medida en la que las pruebas utilizan el código, qué casos prueban y qué parte del código se utiliza; esta medida nos ayuda a saber qué tan efectivas son las pruebas que hemos diseñado.

Solución

En el ámbito del Desarrollo de Software se considera una solución a una aplicación o conjunto de aplicaciones que brindan la funcionalidad deseada por el usuario final; normalmente éstas pueden ser un producto del mercado, por ejemplo: hojas de cálculo tales como Microsoft Excel o procesadores de textos tales como Microsoft Word, o las soluciones que pueden ser desarrolladas a medida en base a una necesidad especial del usuario final.

Bugs

Defectos en el código que producen comportamientos extraños o resultados no deseados en la solución desarrollada.

Items de Trabajo

Elementos de información tales como tareas, listas de cualquier tipo de elementos, y otros elementos tales como Bugs que estén relacionados con el trabajo del desarrollador.

Team Foundation Server

Es la parte de Visual Studio Team System que se encarga del manejo de ítems de trabajo, documentos, reportes, y otros elementos, ya sea información entregada al equipo de desarrollo o información como resultado del mismo.

Refactoring

Nueva característica que nos provee Visual Studio en todas sus ediciones, ésta consiste en reconstruir partes del código, de ser necesario, como por ejemplo el cambio de nombre de un método, o el cambio del orden de los parámetros de un método; éstos necesitan actualización en toda nuestra solución. De esto se encarga el Refactoring.

Metadata

Conocida también como "datos de los datos", es una descripción de su contenedor; por ejemplo, puede ser un archivo que contenga información acerca de un cierto proyecto.

Administrador de Pruebas

Es una interfaz que provee Visual Studio Team System para administrar pruebas manuales o automatizadas de código.

3. Escenario de Ejemplo

Vamos a suponer que uno de nuestros clientes nos ha solicitado crear una solución que permita colocar una tienda virtual de sus productos y que desde sus oficinas principales puedan realizar el control en tiempo real de las órdenes que se realicen desde la tienda, con el fin de verificar que disponen de la cantidad suficiente de productos; es muy importante también para los ejecutivos de dicha organización tener acceso inmediato a reportes de ventas y también de otras operaciones medibles gracias a la solución que se implantará.

Conociendo esto y algunos otros detalles que se han obtenido por varias entrevistas a las personas encargadas, la antes mencionada organización para quienes realizaremos la solución se ha decidido que la solución debe contener básicamente 3 aplicaciones, las cuales son (Ver Figura 1):

Bb972265.art257-img01-570x306(es-es,MSDN.10).jpg
Figura 1: El Diagrama de Aplicaciones puede ser agregado a la solución como un Nuevo Diagrama de Sistemas Distribuidos.Volver al texto.

  • Tienda Virtual: Un sitio ASP .net 2.0 que mostrará los productos de la tienda, asimismo permitirá que los usuarios se registren para realizar compras.

  • Servicio Web: Funcionará como una capa de negocios, la cual recibirá los pedidos desde la Tienda Virtual y el registro de usuarios, así como también manejará las solicitudes de información para los reportes en la oficina central; esta misma capa tendrá métodos internos para el acceso a la base de datos.

  • Generación de Reportes: Esta será una solución con Office System, específicamente con Microsoft Excel, que permitirá consultar la información necesaria desde nuestro Servicio Web para el normal funcionamiento de la organización.

Un dato adicional que el departamento de mercadeo de la organización nos proporciona, es que se calcula que inicialmente la tienda virtual recibirá alrededor de 500 visitas diarias, y realizará 250 ventas diarias; al cabo de 6 meses se ha proyectado que recibirá alrededor de 5000 visitas diarias y se realizarán más de 3.000 transacciones de venta por día.

Teniendo en cuenta la arquitectura de la solución, nos encontramos con que nuestro Servicio Web es el corazón de la solución; esto nos indica que debe estar muy bien probado en todo sentido, y aún más con el dato de posible crecimiento que nos indica el departamento de mercadeo de la organización.

Vamos a suponer que se ha organizado ya el equipo de desarrollo para realizar las diferentes tareas separadas por las aplicaciones antes mencionadas, y que hemos sido ubicados en el equipo de desarrollo del Servicio Web; nuestra responsabilidad es elevada por la razón de que nuestro trabajo permitirá el normal funcionamiento del resto de aplicaciones que componen la solución.

El resto de los desarrolladores están realizando ya su trabajo, asimismo nosotros debemos comenzar con el nuestro; en el Diagrama de Aplicaciones, el Arquitecto de nuestro equipo ha definido ya los métodos que deben ser implementados para el funcionamiento de la solución y ha sido ya construido el esqueleto de la misma; ahora es nuestra responsabilidad dar la funcionalidad necesaria a los mismos (Ver Figura 2):

Bb972265.art257-img02-570x366(es-es,MSDN.10).jpg
Figura 2: El Arquitecto puede definir en el Diagrama de Aplicación los métodos que nuestro Servicio Web va a exponer en los detalles del Servicio Web, antes de que éste sea implementado. Volver al texto.

Para este momento, en la parte del Servicio Web, tenemos 2 servicios: Negocios y Servicios. Se lo ha diseñado con esta separación teniendo en cuenta la seguridad necesaria para nuestra aplicación. Para comenzar con la implementación de dichos servicios contamos con un diagrama de clases que Visual Studio 2005 es capaz de generar; con este diagrama podemos ver las clases con todos sus elementos, así como modificarlas agregándoles elementos (variables, métodos, constantes, eventos), aplicando los conceptos de la Programación Orientada a Objetos, tales como la encapsulación, generar interfaces de dichas clases, etc., en nuestros caso sólo agregaremos una constante en cada servicio (Ver Figura 3):

Bb972265.art257-img03-570x406(es-es,MSDN.10).jpg
Figura 3: Diagrama de clases que representa a los Servicios Web ya implementada su estructura. Volver al texto.

Cuando se ordena que se implementen estos proyectos siempre los métodos contendrán el siguiente código:

/// <summary>
/// Ingresa un nuevo producto
/// </summary>
/// <param name="pstrDescripcion">descripción del Producto</param>
/// <param name="pintCantidad">Cantidad ingresada</param>
/// <param name="pdblPrecio">Precio del Producto</param>
[System.Web.Services.WebMethod(), System.Web.Services.Protocols.SoapDocumentMethod(Binding = "Servicios")]
public void IngresarProducto(string pstrDescripcion, int pintCantidad, double pdblPrecio)
{
    throw new System.NotImplementedException();
}

Con la última línea nos aseguraremos de que si por un descuido este método no se llegara a implementar, al llamarlo a funcionar nos arrojará una excepción que nos permitirá tomar nota de esto.

Para nuestros propósitos implementaremos 2 métodos: MostrarClientes y MostrarProductos; para esto implementaremos un proyecto de librería de clases el cual contendrá los métodos necesarios para realizar estas operaciones; este Proyecto se llamará TestCL, el código de MostrarClientes es el que se muestra a continuación:

/// <summary>
/// Devuelve la lista de clientes activos
/// </summary>
[System.Web.Services.WebMethod(), System.Web.Services.Protocols.SoapDocumentMethod(Binding = "Servicios")]
public DataTable MostrarClientes()
{
    return clsDatos.MostrarClientes();
}

Y el código de MostrarProductos es el que se muestra a continuación:

/// <summary>
/// Devuelve los productos con sus cantidades
/// </summary>
[System.Web.Services.WebMethod(), System.Web.Services.Protocols.SoapDocumentMethod(Binding = "Servicios")]
public DataTable MostrarProductos()
{
    return clsDatos.MostrarProductos(); 
}

El código de la clase es el que se muestra a continuación:

public class clsDatos
{
    public static string ConnString;
 
    public static DataTable MostrarClientes()
    {
       if (string.IsNullOrEmpty(ConnString))
          throw new Exception("The Connection String wasn't configured");
 
       DataTable dtbResult = null;
 
       using (SqlConnection sqlCon = new SqlConnection(ConnString))
       {
          SqlDataAdapter sqlAda = new SqlDataAdapter("select * from Person.Contact", sqlCon);
 
          try
          {
             dtbResult = new DataTable();
             sqlAda.Fill(dtbResult);
          }
          catch
          {
             dtbResult = null;
             throw;
          } 
       }
       return dtbResult;
    }
 
    public static DataTable MostrarProductos()
    {
       if (string.IsNullOrEmpty(ConnString))
          throw new Exception("The Connection String wasn't configured");
 
       DataTable dtbResult = null;
 
       using (SqlConnection sqlCon = new SqlConnection(ConnString))
       {
          SqlDataAdapter sqlAda = new SqlDataAdapter("select * from Production.Product", sqlCon);
          try
          {
             dtbResult = new DataTable();
             sqlAda.Fill(dtbResult);
          }
          catch
          {
             dtbResult = null;
             throw;
          } 
       }
       return dtbResult;
    }
}

Algo que se debe notar en estas porciones de código es que todas ellas deben tener la descripción que se definió en el Diagrama de Aplicaciones que realice al arquitecto; esto, además de proveer de cierta facilidad al desarrollador y a otras personas que utilicen el código al conocer cuál es el propósito de éste, provee consistencia entre los modelos realizados y el código; cabe mencionar que si por cualquier razón se modificara el código, esto se reflejaría en la medida de lo necesario en el modelo ya antes generado; de esto es responsable una nueva característica de Visual Studio llamada Refactoring.

Así podremos seguir implementando el resto de los métodos tal como sea necesario implementarlos. De aquí en adelante el siguiente paso será probarlos; hay varios métodos para hacerlo, especialmente manuales. Por ejemplo, podremos hacer que se ejecute nuestro Servicio Web y revisar los métodos invocándolos por la interfaz que genera el .net framework para éstos, o bien usar un proyecto que haga referencia a estos para revisar ahí los resultados. Con Visual Studio Team System tendremos la posibilidad de crear proyectos enteramente dedicados a realizar pruebas de nuestro código; usaremos estos proyectos para conocer la funcionalidad y los beneficios que éstos nos ofrecen sobre otros métodos de prueba.

4. Creando y configurando las pruebas

Para conseguir nuestro objetivo agregaremos a nuestra solución un proyecto enteramente dedicado a pruebas; para esto, Visual Studio nos provee con proyectos de tipo Pruebas (Test Project). Podremos agregar este proyecto dando clic derecho sobre el ítem de la solución, en el Explorador de Soluciones, y escogiendo Agregar | Nuevo Proyecto, aparecerá el cuadro de diálogo que muestra la Figura 4:

Bb972265.art257-img04-570x373(es-es,MSDN.10).jpg
Figura 4: Cuadro de diálogo para escoger el proyecto de prueba a crear. Volver al texto.

Después de seleccionar un nombre para el nuevo proyecto daremos clic sobre OK y cuando se termine de agregar, podremos observar los distintos elementos que se han agregado a este proyecto. Se debe mencionar que este tipo de proyectos está disponible para Visual C#, Visual Basic .net y Visual C++ (Ver Figura 5):

Bb972265.art257-img05-195x345(es-es,MSDN.10).jpg
Figura 5: Proyecto de prueba agregado a la solución con sus respectivos elementos. Volver al texto.

Revisaremos a continuación cuál es la función de cada ítem que contiene el proyecto de prueba:

  • AuthoringTest.txt: Contiene una breve guía de cómo crear y ejecutar las pruebas, así como qué tipos de pruebas ofrece Visual Studio.

  • ManualTest1.mht: Este es un documento de plantilla que permite realizar pruebas manuales, este elemento también puede ser objeto de seguimiento en Visual Studio.

  • UnitTest1.cs: Contiene una clase con métodos de guía para construir las pruebas; cada método es tomado como una prueba por separado.

También se agregan dos elementos a los archivos de la solución y estos son:

  • Localtestrun.localtestconfig: Este es un archivo XML que contiene las configuraciones para ejecutar las pruebas; entre estas configuraciones están las configuraciones de cubrimiento de código, donde se ejecutarán las pruebas; si éstas se harán en ASP .net o localmente, etc.

  • NombreDeLaSolucion.vsmdi: Este archivo contiene metadata de las pruebas donde se contiene información general de las pruebas. Si se da doble clic en este archivo, se abrirá el Administrador de Pruebas.

Conociendo un poco más el entorno de las pruebas, procederemos a configurarlas de modo que nos presten la mejor funcionalidad para nosotros como desarrolladores. Primero, le agregaremos a nuestro proyecto de prueba una referencia al proyecto TestCL para poder acceder a los métodos a ser probados; es preferible que una vez realizado esto, hagamos una compilación de la solución entera; luego de esto daremos doble clic al archivo Localtestrun.localtestconfig y se abrirá el cuadro de diálogo que muestra la Figura 6 donde configuraremos las distintas opciones, especialmente las de cubrimiento de código:

Bb972265.art257-img06-570x368(es-es,MSDN.10).jpg
Figura 6: Cuadro de diálogo que nos permite configurar las diversas opciones para ejecutar las pruebas. Volver al texto.

Como se puede observar, dentro del cuadro de diálogo podremos escoger entre varias opciones, entre las cuales se encuentran 2 elementos repetidos; seleccionaremos el elemento TestCL.dll que está en la ruta: <DirectorioDeLa Solución>\<NombreDelProyectoDePrueba>\bin\<ConfiguracionActual>, esto nos permitirá que a medida que las pruebas se ejecuten, se vayan recolectando datos sobre el código tal como veremos más adelante; podemos seleccionar cuantos elementos deseemos, pero no de nombres repetidos; será mejor seleccionar los elementos que tienen la referencia al proyecto de pruebas por cuanto son el resultado de las últimas compilaciones. Luego, daremos clic en Guardar o simplemente en Cerrar, tras lo cual el sistema nos pedirá confirmación para guardar los cambios, en el último de los casos.

Si bien se nos provee una clase en el proyecto que ya puede alojar pruebas, también podremos usar un asistente que implementará distintos tipos de pruebas según lo que escojamos; en nuestro ejemplo, escogeremos las pruebas unitarias: para ello, en el proyecto de prueba, daremos un clic derecho sobre el nombre del proyecto y escogeremos Agregar Nueva Prueba Unitaria (Ver Figura 7):

Bb972265.art257-img07-513x332(es-es,MSDN.10).jpg
Figura 7: Opciones que se nos muestran para agregar las diferentes pruebas que se pueden realizar. Volver al texto.

Cuando realicemos esto, se nos aparecerá un cuadro de diálogo en el cual podemos seleccionar para qué parte de nuestra solución se van a generar las pruebas, así como algunas configuraciones tales como los nombres de las pruebas, los archivos que contienen las clases y otras opciones útiles (Ver Figura 8 y Figura 9):

Bb972265.art257-img08-570x440(es-es,MSDN.10).jpg
Figura 8: Cuadro de diálogo donde podemos seleccionar para qué parte de la solución se generaran las pruebas. Volver al texto.

Bb972265.art257-img09-315x342(es-es,MSDN.10).jpg
Figura 9: Cuadro de diálogo donde podemos seleccionar para qué parte de la solución se generaran las pruebas. Volver al texto.

Al dar click sobre el botón OK se generarán las pruebas; éstas se encontrarán dentro de una sola clase, marcadas con atributos que hacen que tanto Visual Studio como .net Framework sepan que son pruebas; al estar dentro de una clase, podremos ver su estructura dentro del Diseñador de Clases (Ver Figura 10):

Bb972265.art257-img10-197x217(es-es,MSDN.10).jpg
Figura 10: Clase de prueba generada, vista en el Diseñador de Clases. Volver al texto.

Estas pruebas no solo se generan para métodos si no también para constructores y propiedades, siendo estos métodos especiales, el código de un método de prueba es, por ejemplo, el siguiente:

/// <summary>
/// A test case for MostrarClientes ()
///</summary>
[TestMethod()]
public void MostrarClientesTest()
{
    global::System.Data.DataTable expected = null;
    global::System.Data.DataTable actual;
 
    actual = TestCL.clsDatos.MostrarClientes();
 
    Assert.AreEqual(expected, actual, "TestCL.clsDatos.MostrarClientes did not return the expected value.");
    Assert.Inconclusive("Verify the correctness of this test method.");
}

Como podemos observar, existen algunos elementos que tal vez a muchos resulten extraños, vamos a explicarlos uno por uno:

  • [TestMethod()]: Este es el atributo que le indica a Visual Studio que el método debe ser considerado como una prueba.

  • Assert: Es una clase con métodos estáticos como AreEqual, Fail, IsNull, IsTrue, entre otros, que nos permiten comprobar valores que pueden ser resultados de las pruebas; si alguno de estos métodos falla en su ejecución, normalmente la prueba es tomada como fallida.

Con la clase Assert podremos establecer los valores de los resultados de las pruebas, así como cuando invocamos el método Fail la prueba se tomará como fallida, o cuando se invocamos el método Inconclusive el resultado de la prueba será inconclusa, pero de no invocar ninguno de estos métodos o no lanzarse una excepción, el resultado de la prueba será correcto.

Como mencionamos antes, y se puede observar en el código, la estructura de la prueba nos indica que se debe comparar el resultado del método con el valor esperado; de configurar el valor esperado nos debemos encargar, por eso cambiaremos el código del método para que la comparación sea correcta y la prueba pueda ser correcta:

/// <summary>
/// A test case for MostrarClientes ()
/// </summary>
[TestMethod()]
public void MostrarClientesTest()
{
    int expected = 0;
    int actual;
    TestCL.clsDatos.ConnString = "Data Source=(local);Initial Catalog=AdventureWorks;Integrated Security=True";
 
    actual = TestCL.clsDatos.MostrarClientes().Rows.Count;
    if (actual <= expected)
    Assert.Fail("TestCL.clsDatos.MostrarClientes did not return the expected value.");
}

No vamos a cambiar los otros métodos con el propósito de ver qué sucede cuando se ejecuten, con estos pasos estamos listos para comenzar a ejecutar las pruebas y analizar sus resultados.

5. Ejecución y Análisis de las Pruebas

Una vez creadas y configuradas las pruebas podemos proceder a ejecutarlas; para ello debemos abrir el Administrador de Pruebas, bien podemos dar doble clic sobre el archivo NombreDeLaSolucion.vsmdi o en el menú Pruebas seleccionar Administrar y Ejecutar Pruebas; al hacer esto se nos mostrará una interfaz como la que se muestra en la Figura 11:

Bb972265.art257-img11-570x391(es-es,MSDN.10).jpg
Figura 11: El Administrador de Pruebas nos permitirá ejecutar y analizar las pruebas y sus resultados. Volver al texto.

Como se puede observar en la Figura 11, el Administrador nos permite seleccionar pruebas de la lista que se construye de los métodos que se encuentran marcados con el atributo [TestMethod()] dentro de cualquiera de las clases del proyecto de prueba; asimismo podemos observar que en la parte inferior se nos muestra una ventana con los resultados de la ejecución de las mismas; en ella seleccionaremos todos los métodos para que se ejecuten y generar los resultados. Para ejecutar las pruebas podemos utilizar el botón con el signo de exclamación verde que se encuentra en la interfaz, o bien elegir en el menú la opción Iniciar las Pruebas Seleccionadas (Ver Figura 12):

Bb972265.art257-img12-570x237(es-es,MSDN.10).jpg
Figura 12: Ventana con los resultados de las pruebas, nombre, proyecto y el mensaje de error, de existir uno. Volver al texto.

En la Figura 12 podemos notar claramente los resultados que pueden tomar las pruebas; todos estos, a excepción del resultado Pendiente, son controlables a través del código. Los resultados explicados son los siguientes:

  • Pendiente: Este estado puede darse por que se ha pedido que se ejecute una prueba manual o bien porque se va a ver cuando una prueba está esperando por ser ejecutada.

  • Inconclusa: Este resultado es normalmente incluido por las pruebas generadas, nos indica qué prueba no se puede concluir o determinar su resultado por alguna razón.

  • Pasada: La prueba se ha ejecutado exitosamente.

  • Fallido: La prueba obtuvo resultados que no se esperaban o se lanzó una excepción en la ejecución del método.

Si hacemos doble clic sobre cualquiera de los resultados se nos mostrará una pantalla con los detalles de la ejecución; estos resultados son muy útiles al momento de encontrar errores en los métodos o en la implementación de las pruebas; también se pueden iniciar las pruebas en modo Depuración para poder pasar línea por línea dentro de éstas y verificar que estén correctamente implementadas. Esto se logra cuando en el botón de ejecutar pruebas hacemos clic sobre la flecha ubicada del lado izquierdo del botón, que producirá la aparición de una opción llamada Depurar las Pruebas Seleccionadas (Ver Figura 13):

Bb972265.art257-img13-570x330(es-es,MSDN.10).jpg
Figura 13: Detalles de la ejecución de una de las pruebas. Volver al texto.

Para revisar los resultados del cubrimiento de código debemos, en el resultado de las pruebas, seleccionar una de ellas dando un clic derecho sobre el resultado y luego seleccionando la opción Cubrimiento de Código (Ver Figura 14):

Bb972265.art257-img14-386x254(es-es,MSDN.10).jpg
Figura 14: Menú para mostrar el resultado del cubrimiento de código. Volver al texto.

Al hacer esto se nos mostrará en la misma ventana los resultados donde podremos observar en un orden jerárquico de objetos, y desglosado en porcentajes y números, cómo se ha cubierto el código, ya sean bloques de código o líneas. Estos resultados son una gran ayuda para conocer qué tan efectivas son nuestras pruebas, parte por parte y globalmente (Ver Figura 15):

Bb972265.art257-img15-570x171(es-es,MSDN.10).jpg
Figura 15: Resultados del cubrimiento de código. Volver al texto.

Aún hay más. Es ya un muy buen comienzo tener estos resultados y saber que tan efectivas son las pruebas, pero ¿Qué parte del código se ejecutó y qué parte no? Esta pregunta se puede contestar fácilmente, si revisamos el archivo de código que las pruebas examinaron y habilitamos la opción Mostrar Cubrimiento de Código; en el código, las líneas se pintarán de verde cuando hayan sido ejecutadas y de rojo cuando no; para habilitar esta opción debemos agregar a las barras de herramientas la Barra de Herramientas de Pruebas, dando un clic derecho sobre las barras de herramientas y seleccionando esta opción. Una vez hecho esto, en la barra aparecerá la opción Mostrar el Cubrimiento de Código (Ver Figuras 16 y 17), daremos un clic y podremos observar los resultados (Ver Figura 18:):

Bb972265.art257-img16-17-570x478(es-es,MSDN.10).jpg
Figura 16: Selección de la Barra de Herramientas de Pruebas.

Figura 17: Botón Mostrar Cubrimiento de código. Volver al texto.

Bb972265.art257-img18-570x350(es-es,MSDN.10).jpg
Figura 18: Código con el cubrimiento expuesto. Volver al texto.

Con todos estos resultados a mano, podemos cumplir con la práctica Test Driven Development eficientemente.

6. Conclusión

La práctica Test Driven Development brinda muchos beneficios al desarrollo de software, tales como el eficiente aseguramiento de la calidad del producto de desarrollo, así como la reducción de bugs y los problemas que suceden cuando las soluciones entran en producción generando además una reducción de costos de soporte del producto. Es notable cómo Visual Studio Team System nos da facilidades para realizar esta práctica aprovisionándonos de herramientas tales como los Proyectos Dedicados a las Pruebas, Cubrimiento de Código, Análisis de Resultados Numéricos y Visuales. Además, estos resultados se integran con Team Foundation Server aportando los resultados para estadísticas y resultados globales del desarrollo, que se ven reflejados en los reportes que nos provee este servidor.

Francisco Lomas trabaja como Desarrollador de Aplicaciones en una empresa de desarrollo de software ubicada en Quito, Ecuador. Posee experiencia con .net desde la versión 2002. Cuenta con la certificación MCAD para C# .net y desarrollo Windows y Web con Visual Basic .net.

Mostrar:
© 2015 Microsoft