Como funcionan los “Impacted Tests” de VSTS 2010

Una de las nuevas funcionalidades de Visual Studio Team System 2010 (en la versión de Developers), es la de los test “impactados”. Esta pequeña funcionalidad, está destinada a ahorrarnos mucho tiempo a la hora de hacer Test Driven Development en nuestros desarrollos.


Recordemos, que una de las grandes máximas en el TDD, es que los tests se ejecuten rápido, ¿y qué modo más rápido que ejecutar sólo los que se ven afectados por el código que acabamos de tocar?, aqui es dónde entra el análisis de test afectados (queda mejor que impactados) de VS 2010.


Sin embargo, tras hablar con algunos compañeros, parece que no está muy claro como hacer funcionar esta pequeña ayuda, y lo cierto es que está un poco rebuscado, veamos a ver si lo puedo contar aquí.


Antes de nada, decir que doy por supuesto que sabemos crear pruebas unitarias, crear una lista de pruebas, habilitar la cobertura de código (esto ha cambiado un poco en VS 2010), y empezar a crear una Team Build en el Team Explorer, no lo cuento aquí por no hacer un artículo muy largo. Si alguien no conoce este tipo de cosas que lo diga y lo contaremos por aquí. Cualquiera que haya hecho esto en TFS 2008, no debería de tener problemas para seguir estas instrucciones.


Lo primero que tenemos que tener en cuenta, es que, para que VS 2010 se de cuenta de que tests están afectados, necesita información de que tests ejecutan el código que estamos modificando, ¿lógico no?. ¿y de dónde lo saca?, pues de las builds de Team Build, si, necesitamos resultados previos de una Team build.


¿Y que datos necesita de la Team Build?, pues lo primero necesitamos, que las pruebas que se ejecuten durante la Team Build, publiquen información de cobertura de código (code coverage). Esta es la primera base para esta información. Además, con las nuevas Team Build (basadas en WorkFlow), necesitamos ejecutar un paso más, que es la publicación del análisis de test afectados, que por defecto está DESACTIVADA. Vayamos al grano.


Una vez que ya tenemos nuestro proyecto, con sus listas de pruebas y la cobertura de código habilitada para el ensamblado que estamos probando, hmmm vale, si estoy dando por supuesto que todos sabéis hacer esto, si no sabéis, dejadme un comentario y lo cuento otro día. Vamos a crear una nueva Team Build.


Y aquí ya empezamos con VS 2010, una vez que estamos en la pantalla de crear una nueva Build, tenemos una sección “Process”, si pulsamos en ella veremos lo siguiente:


image


Lo primero, pulsaremos el primer link (“Select solutions …”), que nos llevará aquí:


image 


Dónde con el botón de los “…” seleccionaremos los proyectos que queremos compilar. Después, seleccionamos el link de “Select tests”, y nos llevará de nuevo a la sección anterior pero esta vez a TestProjects, volvemos a pulsar los puntos suspensivos, y se nos mostrará la ventana para seleccionar el fichero “.vsmdi” que corresponde con los tests que queremos ejecutar (y sus correspondientes listas).


Y ahora viene la magia para los impacted tests, ya que tenemos que activar unas cuantas opciones del proceso.


La primera es esta:


image Vamos desplegando el proceso de este modo: “Select an agent …”, “Compile and test”, “Get Impacted tests”, y ohhhh, vemos que está a false (a la derecha), pues la ponemos a true.


Seguimos desplegando por la rama “Test All Projects”, “Test a Project”, “Run MSTest …”, y llegamos aquí:


image


Ohhh, segunda sorpresa, la actividad (a la derecha) “PublishTestImpactInformation” está a false, pues nada, la ponemos a true.


Y seguimos adelante, y en la sección “Publish the Test Impact Data”:


image


Ohhh, tercera sorpresa, también a false, pues nada, la ponemos a true.


Con esto (y el resto de propiedades de la Team Build habituales), ya tenemos la Build preparada para tener información de los test afectados.


Pero hay más trucos, debemos de ejecutarla al menos DOS veces antes de tener información, la primera vez, se establece la línea base de código, y la segunda ya tenemos la información necesaria para el análisis.


Una vez que la hemos ejecutado dos veces (y que haya funcionado con información de cobertura incluida), ya estamos en disposición de probar esta funcionalidad.


Para ello, abrimos la solución de nuevo (en caso de haberla cerrado), y seleccionamos el menú “Test”, “Windows”, “Test Impact view”.


Y más “trucos”, tenemos que seleccionar en esta vista, el proyecto al que pertenece, y la build de la que queremos obtener la información de tests:


image Con esto, y si hemos seguido todos los pasos, una vez que empecemos a modificar código, y grabemos los cambios (sin necesidad de hacer check-in), veremos como en la sección de Impacted Tests, nos van apareciendo los tests a los que afectan estos cambios.


En fin, es un poco lioso, lo se, y espero que para la versión final esto cambie (ya les he dado el feedback), pero por ahora, eso es todo lo que tenéis que hacer 🙂


Y bueno, para cualquier duda aquí (http://www.lfraile.net) me tenéis.




Este post es cross-posting desde http://www.lfraile.net  y estoy muy interesado en tu opinión. ¿te vienes por aquí y me dejas un comentario?

Deja un comentario

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