facilitar el trabajo con pruebas: PEX

Creo que en los últimos años no ha variado la cantidad de gente que trabaja con tests… han evolucionado los frameworks, se han creado nuevas herramientas… pero no ha habido demasiada adopción, no se ha transmitido correctamente el valor de los tests y no se ha invertido el suficiente tiempo en ellos. Quien hacía pruebas en el 2009… es porque las hacía desde el 2003 🙂

Por fin… en el 2010 😀 parece que poco a poco va entrando en la cabeza de los equipos la rentabilidad de probar el código de una forma formal y sostenible y de una forma u otra los equipos van haciendo sus pinitos.

Para estos equipos que se inician, para quién quiere probar herramientas nuevas o para quien tiene código heredado que no sabe como atacar…llegan dos addins de visual studio  ( de la mano de Microsoft Research ) que facilitan la generación y el trabajo con puebas.

Microsoft Moles 2010::

Resumiendo, es un framework de mocks. Si nunca has trabajado con un framework de mocks, su misión es ayudarnos a aislar el código de dependencias externa, permitiendo reemplazar métodos y propiedades por equivalentes para pruebas.

<breve intro a lo que es un mock>

Supongamos que estamos validando la funcionalidad de sumar dos enteros (original, eh?) Y los valores de esos enteros, se leen de una BBDD.

Ahora supongamos que al lanzar el test, éste falla porque la red esta mal configurada y no se puede resolver el nombre del servidor SQL. Eso NO es lo que buscabamos en este test… lo que queremos probar es si es capaz de SUMAR correctamente.

Vamos  mockear el acceso a bbdd. Vamos a suplantar esa llamada, de modo que el nuevo método devuelva dos enteros, sin más, sin ir a bbdd ni nada, para que la prueba de la Suma pueda centrarse en su ámbito.

</breve intro a lo que es un mock>

Microsoft PEX 2010::

El nivel  básico es conceptualmente sencillo. En base a un análisis del código, crea tests con las entradas necesarias para ejecutar todas las ramas existentes en el código ( todas las posibilidades de if, switch… ) y descubrir posibles excepciones o errores.

Además nos deja personalizar esos tests o recoger información relativa a la cobertura de código ( cobertura en VS Premium o Ultimate ).

En este post nos centraremos en PEX y en otro posterior atacaremos Moles 😉

 

¿Cómo funciona PEX?

Una vez instalado, PEX funciona a través de un menú de contexto en Visual Studio, lo invocaremos para inspeccionar una clase o método y nos mostrará una ventana con pares de información introducida y resultado obtenido.

Es MUY sencillo obtener esta información… simplemente hay que ejecutar PEX… y éste se encargará de ejecutar varias veces el código seleccionado con diferentes opciones de entrada ( Exploraciones PEX )

nota… la primera vez que ejecutas pex te pide que selecciones un framework de tests

Y el resultado…

 

Vemos que entradas ha probado null, “”, “” … y que en todas ha ido sin problemas excepto en la primera, PEX ha detectado que este método podría generar un NullReferenceException Leyendo el código se nos podía haber escapado ( y no digas que no que el software esta lleno de despistes como este )… y puede que si hacemos los test a manos estemos demasiado centrados en lo que debe pasar y no en lo que pueda pasar…pero al analizar todos los statements y sus ramas, lo ha cazado 🙂

Al hacer click sobre la excepción en la ventana de PEX nos da información adicional del stack y detalles del test creado.

 

Y hasta nos permite mandársela por mail a quién consideremos oportuno

 

Algo más avanzado… precondición y asunción

Imaginemos que este método no tiene que tratar esa posibilidad de parámetro = null porque siempre se le llama con un valor correcto. En ese caso sería el componente que llama el responsable de controlar el valor del parámetro.

En la imagen anterior podemos ver que hay una opción Add Precondition, si nos situamos sobre la opción, nos muestra un pop up donde vemos una posible forma de tratar el error.

Si hacemos click, pex modifica nuestro código añadiendo la precondición para propagar la excepción al que invoque

Personalmente no me gusta esta solución, lanzar una excepción nueva no es solucionar el error. PEX nos da opciones ms elegantes, como añadir Assumptions al caso de prueba. Podriamos indicarle al test que asumimos que ese parametro nunca va a ser null y evitamos la excepción.

Tendríamos que guardar el test fallido (o todos, al gusto),y editar la clase que inicia las pruebas.

Así podremos indicarle que asuma que el valor no es nulo.

Y al volver a ejecutar los tests… evitarnos la excepción 😉

La funcionalidad de explorar las ramas con diferentes valores hace a PEX útil desde el minuto 0, pero como véis, además podéis entrar dentro del framework y trabajar a un nivel mayor de detalle.

Discusión… tiene sentido PEX en un entorno TDD?

Aquí me gustaría abrir algo de debate a ver qué opináis… sé que los comentarios no son un foro… pero permitidme la licencia 😉

Para mi tiene todo el sentido… TDD para aceptación y funcionalidad y PEX para descubrir despistes y dar información de cobertura.

 

Documentación, descarga y demás… –  http://research.microsoft.com/en-us/projects/pex 

Laboratorio de PEX – http://research.microsoft.com/en-us/projects/pex/digger.pdf

Vídeo de Unai en ch9 de intro a PEX – http://channel9.msdn.com/posts/Daniel+Garzon/Introduccion-a-PEX/  (tiene algo más de un año… pero hace el servicio 😀 )

 

Happy hacking!

PD –> Nos vemos con Holanda en la final! ( a ver si no tengo que tachar el comentario mañana tras el Alemania-España xD )