Hola a todos, aquí estoy de nuevo tras un tiempo de inactividad. La verdad es que andaba yo sin ningún tipo de inspiración para un nuevo post cuando el mundo real me ha obligado a escribir este. La verdad es que en estos meses, tanto en conversaciones, como en twitter, como en varios cursos de calidad, agilismo y testing que he impartido, han surgido de manera recurrente las siguientes preguntas: ¿y cómo engancho el selenium en todo esto? ¿Y cuándo grabo las navegaciones para automatizar las pruebas funcionales? ¿Y porque tanto rollo de BDD si ya tengo el producto “Super UI Test Automator Robot” que me graba las navegaciones? Y así una detrás de otra. Reconozco que si no te interesa el enfoque BDD ni el TDD, puedes seguir grabando navegaciones como modo de “automatizar test funcionales”. Para el resto de vosotros os ofrezco varias razones por las que considero que usar éste enfoque es una aberración:
La primera razón es bastante trivial, si haces BDD entonces tienes un enfoque “test first”, es decir, escribes el test antes que la implementación, y no se escribe ni una sola línea de código hasta que no tienes una especificación (test) en rojo. En este sentido es completamente imposible usar el paradigma de grabar navegaciones para automatizar el testing, ya que tienes que tener el test automatizado antes que la implementación y por lo tanto no puedes grabar nada.
La segunda razón tiene que ver con el mantenimiento. Si decidimos que el test de cada escenario de una historia de usuario se va a automatizar grabando una navegación, entonces lo que estamos testeando realmente es la UI y no la funcionalidad propiamente dicha. Cada vez que se produzca un cambio trivial en la UI de una página o panel, vamos a tener que grabar de nuevo todas las navegaciones que usen ese panel o página, aunque la funcionalidad no haya cambiado realmente. Claramente al usar el paradigma de “grabar navegación” estamos acoplando nuestros tests al diseño fino de la interfaz de usuario, que como todos sabemos, cambia con más frecuencia que la funcionalidad propiamente dicha de la aplicación. Un simple cambio en el atributo “name” o “id” de un elemento, o eliminar un botón de “buscar” para hacer una búsqueda en tiempo real, nos va a estropear las navegaciones.
Ojo, también nos podemos meter en este lío haciendo BDD, con por ejemplo Cucumber, si no tenemos cuidado. Pero mi argumento es que si usamos una herramienta que graba navegaciones como base de nuestra estrategia de testing funcional, este problema es inevitable. Por el contrario si decidimos usar un enfoque basado en programar nuestros tests podemos evitarlo fácilmente. ¿Cómo? Simplemente usando el patrón “page object”, e implementar cada “page object” con algún framework de automatización de UI, como WebDriver de Selenium o Watir. De esta forma si se produce un cambio en una UI, que no altere la funcionalidad, entonces sólo necesitamos retocar el “page object” correspondiente, sin necesidad de modificar nada en nuestros tests, escenarios y steps.
El que nuestros tests sean código hecho por nosotros es bueno. Podemos aplicar todas las técnicas de ingeniería del software que conocemos y aumentar la mantenibilidad de nuestros tests. Eso es, recordad que el código de test tiene que ser mantenible, y todo el tema de legibilidad, DRY y SOLID se le aplica, y por lo tanto podemos usar toda nuestra habilidad para que esto se cumpla.
Bien, y esto es todo, ¡ no diréis después que mis posts son muy largos 
!
P.S. Sois programadores, ¡ que no os asuste programar ! ¡ No os escondais en herramientas !
Buen post Enrique. Me han gustado los argumentos que das en contra de la grabación de navegaciones y sobre todo la última frase: ¡Somos programadores, que no nos asuste programar!
Para cuando otro post complementario en el que se vea algo de código?
Je, je, ten cuidado con lo que pides… }:-)
Buena apreciación. Tal vez exista algún escenario donde tiene sentido la grabación de navegaciones, anque es algo bastante relativo. Por ejemplo, yo las emplearía en aplicaciones donde no se utilizaban las técnicas de testing automatizado, a fin de generar un conjunto de test que sirvan como punto de partida para incluir la rutina de trabajo ATDD o BDD. En este caso lo vería interesante, siempre y cuando luego se siga con la filosofía habitual, se refactoricen y se manejen como una parte más del código de la aplicación.
A mi sólo se me ocurre un caso de uso de tales herramientas: cuando no vas a mantener a largo plazo una aplicación. Por ejemplo, una aplicación que va a dar respuesta a una campaña de márketing y a los 3 meses se va a retirar de producción. Si me encuentro con código legacy lo primero es ponerse manos a la obra y cubrirlo con tests.
En mi proyecto actual usamos Page Object con Geb. Nunca he automatizado pruebas grabando la navegación, así que no se cuanto afecta a los tests un cambio de la UI en esos casos. Pero, sí que te puedo asegurar que los tests con Geb tambien se rompen cuando tocas la UI. Aún así, encantado con Geb. Totalmente recomendable.
Por cierto, enhorabuena!. No se si has hecho algún propósito de nuevo año o algo así, pero es la primera vez que consigo leer uno de tus posts sin calificarlo de “infumable”
¿GEB es esto http://www.gebish.org/? Tiene muy buena pinta. Si cuando tocais la UI, sin haber cambiado la funcionalidad, y entonces a veces se rompen un tests, es que no estais usando bien los page objects. Si no hay cambio de funcionalidad entonces lo único que se debería romper son los page objects.
P.S. Ahora estoy haciendo acto de contricción y pienso escribir todos los posts cortitos ¡ Penitencia !
Sí, eso es Geb. Es genial para el mundo Groovy/Grails.
Correcto!. Se rompe el Page Object, y eso a su vez acaba rompiendo el test.
Por ejemplo, tienes un test que hace “click()” en un botón, y luego afirma que ese click te ha llevado a cierta página. Si cambias la UI, y ese botón pasa a llamarse de otra forma, el “mapeo” del Page Object se rompe, ese click() que hace la navegación previa deja de funcionar, y el assert falla.
Por lógica, Page Object debe ser menos sensible a cambios de diseño que la navegación “grabada”, pero romperse, ¡se rompe!.
Yo creo que lo importante de Page Object es que te permite trabajar en modo “el test primero!, idiota!” incluso en la fase de validación de funcionalidades. Es decir, te permite usar paradigma TDD en todas las capas de tu app. Y eso mola!, sobretodo para los que sabéis hacer esa cosa rara!!!
Ah, era entonces una confusión con la palabra “rompe”. Obviamente el test falla porque el page object falla. Lo que yo quiero decir es que sólo necesito modificar el page object, el código del test queda como está.
Cierto!. Tu assert es correcto!.
De acuerdo con geb (+spock en mi caso) aunque en mi primera experiencia ha habido claroscuros: me he encontrado algunos bugs (propios, de webdriver o combinados) y alguna ambiguedad en el api (a cambio de ser flexible). Por otro lado como en todo hay que aprender (geb y algo de webdriver) y coger fluidez a la hora de escribirlos.
Me han salido bastante caros, tal vez demasiado para el tamaño/complejidad de la aplicacion que testeaba, aunque hasta no probar a usarlo con cierta fluidez no se puede evaluar los costes. Son muy, muy fragiles, mas al principio o en fases donde cambia tambien la funcionalidad o su estructura y para que sean lo menos posible tienes que invertir inicialmente mas tiempo todavia puliendo mucho el codigo que automatiza el test.
En la parte positiva resaltaria el valor que te dan como guia para diseñar de dentro a afuera la aplicacion (si los haces primero), la documentacion (pueden ser leidos por alguien no tecnico) y que te caza los bugs que se escapan a la parte unitaria y de integracion, los mas insidiosos y esquivos.
Os dejo un ejemplo de como me ha quedado uno de ellos, comentarios y criticas bienvenidos.
https://gist.github.com/1591228
Cierto!, nosotros también hemos tenido algunos extraños, tanto con el driver HtmlUnit como con el driver para Firefox.
Y totalmente de acuerdo también en que el coste a priori parece alto. En nuestro caso, al meter javascript y ajax de por medio, algunos tests han resultado casi inviables (al menos en tiempos aceptables). También es cierto que es nuestra primera vez, así que habrá que ver que tal evolucionamos cuando tengamos más dominio.
Gracias a tus comentarios este año he empezado con BDD y la verdad es que estas tres primeras semanas (aproveché que empezaba proyecto nuevo) están siendo duras pero el resultado me está gustando, bueno que me desvío de lo que iba a decir…
Si alguno utiliza PHP; Zend framework tiene una librería de test ( http://framework.zend.com/manual/en/zend.test.phpunit.html ) que implementa bastante bien “page object” (desconocía que se llamaba así) y puedes hacer querys de etiquetas HTML, contenido, redirecciones y más cosillas que están bastante bien.