Cómo ejecutar unit test con visual studio

En anteriores entradas he escrito sobre qué son los unit test y su importancia. También lo he hecho sobre cómo preparar tu entorno para hacer unit test y por qué usar la librería rhino mock. Así que ahora ha llegado el momento de explicar como ejecutar tus unit test para comprobar sus resultados.

Si ya has hecho tus primeros test, con los correspondientes data annotations en la clase de test y sus métodos, cuando compiles tu código podrás acceder al explorador de test y encontrar estos test.

Estos data annotations son las siguientes en el caso de estar usando NUnit, como recomiendo en mi entrada sobre “herramientas para unit test“:

[TestFixture], para las clases.

[Test], para los métodos.

En cambio si estas utilizando librerías nativas de microsoft, serán:

[TestClass], para las clases.

[TestMethod], para los métodos.

Podrás ver el explorar de pruebas (de test) abriéndolo desde la pestaña para test. Por defecto suele activarse y estar disponible en el lateral izquierdo.

Su aspecto es el siguiente:

En este caso los test aún no han sido ejecutados, tal como se aprecia tanto en el menú destinado a pruebas como en esta ventana podemos seleccionar la opción de ejecutar los test.

Es posible ejecutarlos todos, o mediante el desplegable ejecutar podrás ejecutar los aún no ejecutados, los no superados o los superados, incluso lanzar un análisis de código que está bajo la cobertura de test (en caso de que tu versión lo permita), de esta última opción hablaré en otra entrada.

También será posible ejecutar una serie de test seleccionandolos previamente en esta ventana, click derecho y ejecutar.

De esta última forma puede ejecutarse o incluso depurarse 1 solo test, algo que también será posible hacer con click derecho sobre el código de tu test.

También será posible crear listas de reproducción, estas se guardan en un directorio específico y pueden compartirse. Crear playlist puede ser útil para agrupar test por diferentes funcionalidades o por razones específicas que sugieran agrupar los test. Lo cierto es que yo nunca he usado esta opción, porque existe un menú contextual que nos facilita categorizar los test, y ejecutar grupos de test por diferentes agrupaciones.

Este menú esta en la parte superior izquierda de la ventana de explorador de test.

Aquí existen 5 tipos de agrupaciones:

Agrupar test por clase

Todos tus test son métodos que pertenecen a una misma clase. Por esta razón es una buena práctica que tus clases de test coincidan con aquellas clases implementadas que contienen tu sistema bajo test. Si por ejemplo tienes la clase “SecurityService”, es recomendable tener una clase de test “SecurityServiceTest”. Siguiendo esta convención, podrás organizar todos tus test por las clases que prueban, y por tanto, si agrupas por clase, podrás ejecutar todos los pertenecientes a una misma clase sobre la que acabas de hacer cambios y deseas comprobar que nada se ha roto.

El aspecto de esta categoría es el siguiente:

Con click derecho sobre cualquiera de estas agrupaciones, podrás ejecutar solo los test contenidos en dicha agrupación.

Agrupar test por duración

Una vez ejecutados los test, también podrás agruparlos por duración. Como comento en mi entrada sobre importancia de los Unit Test, estos deben ser F.I.R.S.T, haciendo la F referencia a su rápidez (Fast), de forma que sea posible ejecutar grandes baterías de ellos en un breve periodo de tiempo. Con esta agrupación podrás ver cuales son tus test mas lentos.

Su aspecto es este:

Más de un segundo ya se consideraría lento, se consideran rápidos a menos de 100ms, aunque realmente en este ejemplo la mayoría de ellos se ejecutan en menos de 10ms.

Agrupación de test por resultado

En este caso te presentará agrupaciones como las anteriores, pero sus categorías serán “superado” (verde), “no superado” (rojo), “saltado” (amarillo)”, o “no ejecutado” (azul).

Agrupación de test por proyecto

Tus clases pertenecerán a proyectos, en caso de que tengas más de 1 proyecto de test con clases de test que contengan métodos, también podrás organizar por esta categoría, podría ser util para probar todos los test de una misma capa.

Agrupación de test por rasgos

Es la que me resulta mas interesante, la he dejado para el final.

Es posible añadir a los test diferentes annotations, con NUnit u otras librerías. En mi caso me gusta NUnit para este propósito, teniendo una gran variedad, como [Category(string)], [Autor(string)], [Description(string)]… Sobre estas diferentes Annotations que NUnit proporciona espero escribir en otra entrada en el futuro.

En todos los test que paso a un mismo sistema bajo prueba (un mismo método), les aplico el mismo category [Category(“nombreClase nombreMétodo”)], de forma que si tienes dudas acerca de si un método funcionará tras aplicar nuevos cambios, puedes encontrar todos los test que aplican a ese método muy rápidamente y ejecutarlos, sin dudar acerca de si tiene test o cuales son sus test. Incluso puedes ver que casos de test son los que le aplican para valorar crear nuevos test que incluyan los nuevos cambios introducidos.

Su aspecto es el siguiente:

En este caso son test de la clase UserDomainService para 3 métodos distintos, cada método tiene 3 casos de test, y se esta aplicando el annotation Category como he definido anteriormente. A un mismo test pueden aplicarle tantos Annotations como se desee, pero hasta ahora no le he encontrado más utilidad que la que he descrito. Localizar muy eficazmente que test aplican al código que estás modificando, con el fin de ampliar los test a los cambios introducidos.

Otra forma de ejecutar los unit test, es desde una perspectiva más relacionada con DevOps, de forma que los test se lancen durante el proceso de CI (Continuous Integration). De esta forma si alguno de tus falla, tu build no se completará y no será desplegada a tus entornos, no entorpeciendo el funcionamiento de tu software por que algo se haya roto con los últimos cambios. Hablaré en otra entrada sobre ello.

Es más, estos test se pueden ejecutar como proceso de una build lanzada al solicitar un pull request de una rama a otra con git, de forma que no sea posible completar el pull request y hacer el merge si estos test fallan, lo cual es un gran mecanismo de control para evitar introducir nuevos errores o bugs. Pretendo hablar también de esto en una serie de entradas que crearé sobre git para el manejo de control de código fuente en una nueva categoría sobre DevOps que crearé en breve.

También continuaré esta serie sobre unit test, ahora que ya tengo diferentes entradas, incluyendo aquellas sobre qué son y cómo ejecutarlos.

Un saludo y a disfrutar programando.

Deja un comentario