Te va a interesar!

6/recent/ticker-posts

Automation Testing con BDD y POM: Cómo manejar las clases?


Hoy se dio un interesante debate con compañeros de Automatizaciones. Al recibir un Pull Request, noté que se estaban definiendo varios métodos en la clase donde se definen los Steps de Cucumber. Viendo ésto, comenté "Estas funciones deberían ir en la clase de la página a la que pertenecen", build desaprobada, a otra cosa mariposa.
Como suele pasar, el que escribió el código se toma como algo personal la crítica y me escribió enseguida: "Pero no puede ser lo que decís! La clase de la página está solamente para definir los WebElements y las acciones sobre ellos, no debería ir ninguna lógica ahí!".

Fundamentos a favor de tener la lógica de las páginas en las clases de ellas.

Soy un tipo sencillo, me gustan mis clases de Step Definitions limpias y con...solamente Step Defs. Si tengo que definir una función que agrupe las acciones para un Login por ejemplo, siempre elijo hacerlo en la clase creada para la página de Login. Definir funciones de varias páginas diferentes en una misma clase de Step Defs, sumado ya a los pasos que tenemos definidos ahí, se me hace desordenado, de poca facilidad para leer y en definitiva, no una buena práctica. 
Definiendo cualquier interacción compleja en la clase de las páginas mantengo la clase de los pasos mucho más limpia y de fácil lectura, enfocándome en COMO se realiza el paso más que en QUÉ acciones en particular tiene que hacer. 
Si hay un cambio en un WebElement, como siempre, se realiza el cambio en la clase de la página. Si hay un cambio en la lógica para, siguiendo con el ejemplo, loguearse a la aplicación, se hace en el método que agrupa las acciones necesaria para tal fin en la clase de página. 
También se presenta la ventaja de tener que cambiar la función en la clase de la página para que todos los usos en los steps automáticamente pasen a usar la última versión, aunque ésto es cierto también en el caso que decidan crear una función en la clase para los Steps. 

Fundamentos en contra de tener la lógica de las páginas en las clases de ellas:

Estos no son MIS fundamentos, son los que se intentaron dar en el debate de hoy por parte de mis compañeros. Hecha la aclaración, pasemos al baile! 

"Si alguien que no sabe toca la clase de la página y la rompe, va a impactar todos los steps que usen esa clase."
Si alguien que no sabe toca el código, va a romper cosas estén donde estén, siendo lo mismo si rompe la función compartida en la clase de Steps Definitions o en la clase de página. No es justificativo para incluir lógica de página en la clase de Step Definitions. El que sigue!

"Cuando creás la clase de la página no sabés qué te va a pedir el test, por lo que no sabés qué funciones crear."
Qué? Pero...qué? Obviamente no vas a saber qué funciones crear hasta no saber qué piden los tests. Una vez lo sepas...las creás en la clase de la página. 

Esos fueron los dos argumentos que siguiendo esgrimiendo, básicamente diciendo que los Page Objects deberían ser simples repositorios de WebElements y llenar de funciones el código de la clase Step Definitions. Luego de buscar ellos mismos cuáles eran las mejores prácticas al respecto, concluyeron en que en el mundo civilizado se hace de la manera que yo planteaba, y hasta conocieron el concepto de Screenplay y lo consideraron para un futuro! Pero eso es otro debate muy diferente que voy a traerles en un próximo post.


Me interesa la opinión de ustedes. Al usar la metodología BDD con POM, cómo definen sus clases de página y de pasos? Están a favor de las funciones en los Step Definitions? Nos estamos viendo en un próximo posteo! 

Nunca dejen de aprender,
The Free Range Tester

Publicar un comentario

4 Comentarios

  1. Y que te parecería un arquitectura de ejecución de pruebas que solo debas programar una sola vez, que incluso los steps sean tan genéricos que puedas reutilizarlos una y otra vez.

    ResponderBorrar
    Respuestas
    1. He estado en esa situación y trabajado así. El tema es que esa complejidad que estás quitando del final del camino, la tenés que tener en algún lado. Podés simplificar todo lo que puedas el uso pero...cuando tengas que hacer mantenimiento puede ser un infierno. Hay herramientas que usan este approach y van muy bien, como el caso de Karate. Karate es API Testing con Cucumber pero realizado de manera tal que no tengas que definir steps porque ya los tenemos definidos!
      Pero esa simplicidad puede ser limitante, sobre todo en casos en los que tenemos que hacer cosas rebuscadas para poder trabajar!

      Borrar
  2. Una pagina puede tener N componentes, un componente puede ser un login, un formulario, un listado de elementos. Cada componente tiene su funcionalidad y su validación.
    Por ejemplo en el listado de elementos una acción es buscar y seleccionar el elemento y una validación podría ser checkear que se selecciono el esperado.

    Con lo cual, desde la clase de steps, tan solo llamamos a la pagina, después al componente y finalmente a su acción o validación.

    ResponderBorrar
    Respuestas
    1. Si, muy bien explicado! Qué opinás de Screenplay en lugar de POM?

      Borrar