El milagro de los panes y los ‘teses’

Logo de Pex


Parece que hay una tendencia cada vez más marcada hacia asegurar la calidad del código fuente y del software mediante herramientas de automatización. Hace poco conocíamos la aparición de Microsoft Source Analysis for C# y de la mano de mi compañero Jose Luis Soria he tenido contacto recientemente con BDD (Behavior Driven Development), una nueva manera de escribir test unitarios realmente prometedora… hoy toca hablar de otra herramienta relacionada con las anteriores.


¿Os imagináis que existiese un software que fuese capaz de analizar un conjunto de pruebas parametrizadas escritas manualmente y a partir de este conjunto generar automáticamente un nuevo conjunto de pruebas con alta cobertura y que además prueban condiciones de frontera? ¿Os imagináis que además este software fuese capaz de indicarnos como corregir potenciales bugs?. Suena casi milagroso ¿no?. Pues bien, gracias a un grupo de investigadores de Microsoft Research, el milagro es posible y se llama Pex (Program EXploration): Automated Exploratory Testing for .Net. El primero que me hablo de esta herramienta fue Juanjo Olabarria uno de los habituales de Artalde y desde entonces he estado esperando con verdadero interés su primera release pública que finalmente se ha producido.


Su integración en el proceso de desarrollo es muy natural. El desarrollador escribe un conjunto de pruebas similares a pruebas unitarias pero que toman parámetros. Luego utilizaremos Pex (que está integrado con Visual Studio) para generar las pruebas unitarias y ejecutarlas. La siguente imagen resume el proceso:


Esquema de utilización de Pex 


La principal duda que me plantea esta herramienta es que al crecer muchísimo el número de pruebas unitarias, el tiempo de ejecución de las mismas se alarga. Y como todo desarrollador acostumbrado a usar pruebas unitarias sabe, la frecuencia con que se ejecutan los test unitarios depende de su velocidad y las pruebas que no se ejecutan frecuentemente son menos útiles que las que sí.


Estad atentos, en próximas entregas os comentaré mis primeras sensaciones con esta herramienta. Los más impacientes podéis ir viendo el screencast que ha publicado el equipo de Pex. Creo que se trata de una herramienta muy prometedora, que permite que con el mismo esfuerzo, lograr test unitarios más efectivos. Supongo que a futuro es algo que veremos integrado en Visual Studio Team System.

8 comentarios en “El milagro de los panes y los ‘teses’”

  1. Gracias, solucionado. Es la asociación con ‘coverage’ que siempre me lleva a cometer este error…

    ¿Qué sería de un sitio que se precie sin un talibán ortográfico? 🙂

  2. Buenas noticias, ya que supongo que se trata de un enfoque mucho más ligero de llevar a cabo test unitarios en el código, sin tener que instalarte por ejemplo un monstruo como “Visual Studio Team System 2008 Test Edition”, ¿no?

    Por cierto, ya que estamos, ¿conocéis a mucha gente que utilice esa versión de Visual Studio Test Edition? Es que me huele a “leyenda urbana de software”, es decir, el típico producto de software del que has oído hablar, pero que luego nunca has visto ni conoces a nadie que lo utilice 😉

    SaludoX.

  3. Lokifasiko, para ejecutar los test no necesitas tener instalado todo VSTS4T solo necesitas MsTest.exe.

    Si es cierto que con Rosario es posible que salga Camano. Que va en la línea de tener una herramienta ligera para ejecutar test, reportar bugs etc…

    Sobre el uso de VSTS4T la verdad es que hay muchísima gente usandolo, sobre todo para las pruebas web y pruebas de carga. Yo lo he usado en varios proyectos.

    En Plain Concepts lo usamos a menudo para tratabajos de mejora de rendimiento, o para buscar bugs o casques que solo se dan bajo carga o incluso para modelar escenarios de prueba para diagnosticar fugas de memoria.

    Lo que si que es cierto es que este pais la calidad de software y el papel del tester está todavía en pañales.

    Un saludo y gracias por el comentario.

  4. Muy buena noticia. Estuve durante un par de años trabajando con pruebas de unidad y hay una parte pesada de la programación de los tests: cuando has de programar todos los tests que prueban un método en sus valores límite para sus parámetros. Era algo “cansado”. Es muy buena idea que haya herramientas que nos faciliten ese trabajo. Y en cuanto a que crecen el número de tests a ejecutar, creo que una solución puede venir por montar un servidor de integración que corra los tests, por ejemplo, por la noche. En esa temporada corríamos alrededor de 3000 tests para una media de 200 métodos públicos y tardaba en ejcutarse alrededor de 15 min. Tiempo sobradamente bien empleado para detectar cambios en las cabeceras de los métodos que afectaban a no-sé-clase-que-se-me-ha-olvidado. :). Repito, muy buena noticia.

Deja un comentario

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