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

image

Y el resultado…

image 

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.

image 

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

image

 

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.

image

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

image

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.

image

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

image

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

image

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 )

Publicado por

6 comentarios en “facilitar el trabajo con pruebas: PEX”

  1. A mí me ha parecido que Moles es mucho más útil a día de hoy. PEX me ha resultado confuso, y los tests que genera no pasarían las métricas de calidad de código que tenemos para todo el código, por lo que o bien habría que evitar pasar sobre el CodeAnalysis y StyleCode, o bien editarlo (lo que haría que perdiera su sentido).

    Además, para poder sacarle la verdadera potencia a PEX tengo la sensación de que habría que hacer un cierto trabajo intensivo con CodeContracts y aserciones, lo cual puede “afear” tu código. Creo que ahora a todo lo que no sea código de negocio lo llaman “ceremonia”, así que con PEX tendríamos que añadir un buen puñado de ella.

    Sobre TDD, creo que haciendo TDD de verdad, uno no debería necesitar PEX. Y si lo usará, sería sin “guardarme” los tests, simplemente al vuelo en un momento determinado a discrección del desarrollador y simplemente por estar doblemente seguro.

    En cambio, a Moles lo veo listo para usarlo mañana mismo y resolver un buen puñado de problemas.

  2. MMMmm… Hace tiempo que probé PEX, y realmente tiene su utilidad aunque finalmente lo descarté porque me encontraba que lo que realmente estaba haciendo era probar mis contratos, cosa de lo que no tengo ninguna necesidad puesto que code contracts ya me los garantiza.

    En mi caso usaba Code Contracts en todos mis métodos públicos para especificar claramente las entradas válidas y las que no. Pex debería ser capaz de procesar esta información y autogenerarse sus propias “asumptions” con ello. Porque lo que NO voy a hacer es añadir un Contract.Requires en todos mis métodos y un PexAssume en todos mis tests.

    Uno debe tener claro el uso de Pex: consigues ratios de coverage altos con poco trabajo pero NO sustituye a tests unitarios hechos a mano, porque obviamente le falta la información de que es lo que hace la “aplicación”. P.ej. los casos de prueba que genera para una función tipo Reverse(string s) son “inútiles”, ya que generará varios tests con s=null, s=”” y s=”” o algo así…

    De todos modos yo probé Pex hace un año o algo así, y no lo he vuelto a probar, así que es posible que algo haya cambiado en todo este tiempo.

    Para mi el peligro máximo es que la gente se crea que con Pex no hace falta realizar “más tests unitarios a mano”.

    Un saludo!

  3. Yep… yo tampoco creo que lo sustituya, lo veo más como un complemento a lo existente que ayuda a prevenir problemas detectando caminos ‘olvidados’ 🙂

  4. Una critica … has comentado muy bien las funcionalidades y capacidades de PEX, pero te has dejado en el tintero la mejor feature de PEX -> el boton para hacerse fan en Facebook !!!

    nice article

    Salu2

  5. He empezado a usarlo en código que tengo x aqui sin tests… Como bien ha dicho David, es una gran y buena ayuda para localizar “despistes”.
    Y haciendo aprecio a la pregunta lanzada: no sustituye a los tests escritos a mano, imho.

Deja un comentario

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