Te comparto en este post algo escrito por Aritz Aguila, quien tiene un muy buen blog que cubre diferentes aspectos técnicos del testing. En este caso, Aritz nos comenta sobre la postura de considerar al tan popular patrón “Page Object” como un antipatrón.
Cuando queremos automatizar pruebas UI de una aplicación web normalmente pensamos en usar Selenium como herramienta y Page Object como patrón de diseño para desarrollar nuestras pruebas.
En mi caso, casi siempre he usado Page Object Pattern en los proyectos en los que he participado.
Hace un tiempo dando una vuelta por el blog de Martin Fowler, llegué hasta un post en el blog de Gauge, donde Soumya Swaroop hablaba del Page Object Model como un antipatrón. Su punto de vista me ha parecido tan interesante que me gustaría compartirlo con vosotrxs mediante este blog.
Incumplimiento del principio YAGNI
Uno de los principios que se incumple es el principio YAGNI, que consiste en no añadir funcionalidad que realmente no sea necesaria. Veamos el siguiente código de la definición de una página con page object pattern:
El incumplimiento del principio viene dado porque los métodos definidos en la página se van a reutilizar, pero los campos solo se utilizan una vez, en los métodos. Normalmente los elementos web que se definen en las páginas sólo son utilizados por una acción.
La propuesta para solucionarlo es trabajar con los locators directamente en el método y no definirlos como campos del objeto previamente.
Si soy sincero, al principio era un poco reticente sobre este cambio, debido a que creía que el tener los elementos como campos me daba una mayor visibilidad de los componentes de la página. Pero si hago una retrospectiva de los proyectos en los que he desarrollado con Page Object Model me doy cuenta de lo poco mantenible que es por los siguientes motivos:
- Definición de elementos que no se han llegado a utilizar.
- Elementos que dejan de utilizarse, pero no se han eliminado de nuestro page object.
- Reusar un elemento para fines diferentes dado que, debido a un mal diseño, comparten el mismo valor para los campos class, name etc.
Incumplimiento del principio de responsabilidad única
El principio de responsabilidad única (SRP) nos dice que cada módulo o clase tiene que tener responsabilidad sobre una única funcionalidad, es decir, en nuestro caso si en el page object definimos la acción de compra, no debería: autenticarse, seleccionar los elementos y comprar.
El no seguir el principio SRP puede hacer que dupliquemos acciones o pasos en nuestros métodos. Como solución al problema Soumya Swaroop nos propone hacer uso de BDD mediante el framework de testing funcional Gauge. De esta forma en las clases desarrollamos los pasos y no la funcionalidad, que se definirá en el fichero de pruebas (spec).
En este caso en el Spec, vemos que se hace uso de los steps desarrollados en la clase po_cart.java. Los demás steps estarán desarrollados en sus clases correspondientes.
De esta forma cumplimos el principio de responsabilidad, podremos reutilizar los pasos y abstraemos un poco más el diseño de la prueba del código.
No obstante, si queremos desarrollar nuestras pruebas con BDD, también podemos usar otro framework con más comunidad, como Cucumber.
Conclusiones
Lo cierto, es que estamos acostumbrados a desarrollar orientado a objetos, tenemos el afán de modelar y definir el “mundo” entorno a nuestra aplicación y sus pruebas. No siempre tiene porqué ser así. Ya conocíamos los beneficios de usar el patrón de Page Object, pero ahora también conocemos la contrapartida.
Usar BDD, con algún framework que nos facilite el desarrollo de las pruebas automáticas, es una buena solución. Ya no solo porque “salvemos” los anti patrones del page object model, si no, porque nos aporta mayores beneficios a la hora de definir las pruebas.
Estuve comentando con un compañero que es “Product Manager” sobre el desarrollo de las pruebas con BDD. Con él, suelo trabajar en la definición de las mismas. Llegamos a la misma conclusión, y es que BDD refuerza el trabajo en equipo, la definición del producto, el desarrollo y el testing.
Podemos trabajar en la definición y el testing de un ítem en la primera etapa del producto, plasmándolo en los Spec. Esto sirve como documentación del ítem para todo el equipo, de tal forma que los desarrolladores pueden ir trabajando en el código mientras el tester y/o el QE trabajan en las pruebas (manuales y automáticas), que podrán lanzar los desarrolladores para testar.
Para terminar, me gustaría compartir con vosotros un tweet de @TestDetective que me pareció muy acertado:
Can you imagine a #SoftwareDevelopment conference with a talk on Java 1.5 in the year of 2018?
…well it’s 2018 and folks are still paying to hear about PageObject Pattern in #SeleniumJava 1.5 release year: 2008
PO pattern first publications: 2008#SoftwareTesting— Lukasz Roslonek (@TestDetective) April 3, 2018
