Te va a interesar!

6/recent/ticker-posts

Qué es el Page Object Model?



Cuando trabajamos con herramientas como Selenium, Ranorex, Katalon o cualquier otra de UI Automation, nos encontramos conque una de los requisitos principales para realizar un trabajo profesional es implementar el Page Object Model. Pero qué es? Es necesario? Qué alternativas hay?

Prepárense un café o té, porque en este post, vamos a responder todas esas preguntas!


Patrones de diseño de software en Testing? Qué es esta hechicería?!

El Page Object Model es un patrón de diseño. Y qué es un patrón de diseño se estarán preguntando... Bueno, hablando mal y pronto es una solución elegante a un problema recurrente. Como siempre les digo, en ingeniería el más vago es el mejor. No queremos volver a inventar la rueda ni repetir cosas. Si creamos soluciones reusables, nos ahorramos trabajo y hacemos las cosas de manera eficiente.

Entonces, el Page Object Model es la solución que se encontró al problema de que las funciones se repiten y las acciones las tenemos que hacer varias veces para diferentes tests. Es muy engorroso tener que cambiar cada implementación cuando algo cambió en el test, por lo que este acercamiento lo que hace es modelar cada página de nuestra aplicación una sola vez y llamar las acciones sobre ella todas las veces que necesitemos, desde una única fuente.

Si algo cambia, solo tenemos que cambiar el origen y todo lo que usaba esa función o parte de nuestra página modelada toma los cambios sin necesidad de tocar nada.

Piensen lo siguiente:
Crean 70 tests que prueban el proceso para comprar distintos artículos llenando distintos campos. Un buen día, un nuevo feature cambia la manera en que accedemos a la aplicación. Sin un patrón de diseño como el Page Object que estamos viendo, tendríamos que actualizar uno por uno los 70 casos de prueba para que pueda acceder a la aplicación de la nueva manera.
Con Page Object, tendríamos una clase para la página de login, en la que en una única función de login estaríamos introduciendo el cambio, para que todos nuestros tests que llaman a esta acción automáticamente estén al corriente. 

Por qué me obligan a usarlo? Es necesario? Qué pasa si no lo hago?

Bueno, si leyeron bien arriba, podrán intuir lo que pasaría en caso de no usarlo. Los tests van a funcionar, si, pero el mantenimiento se va a hacer, más temprano que tarde, insostenible en el tiempo. Cuando en una release los cambios sean numerosos y tengamos que actualizar nuestros scripts, sin un patrón de diseño como Page Object vamos a estar muy comprometidos de tiempo y enseguida vamos a decir "pero por qué no hicimos esto de otra manera?".

Obviamente va a haber excepciones en las que no va a hacer falta por ser demasiado para el producto que se pide. En mi caso, como comentaba en este post, una vez tuve que hacer un login solamente para monitorear la experiencia del usuario en producción. Como ese era todo el alcance de ese repositorio y código, no hacía falta implementar el Page Object Model porque hubiese sido gastar tiempo en algo que no iba a significar ninguna ventaja. Pero de nuevo, son excepciones. 

Qué alternativas hay al Page Object Model? Es lo único que puedo hacer para organizar mis proyectos de Automation?

Por supuesto que no! Hay alternativas y sobre todo las empezás a ver y entender cuando pasás a hacer API Automation. La más popular y la que se considera el avance al Page Object Model es Screenplay.

Imaginen que se hizo un refactor de las clases Page Object Model siguiendo los principios SOLID de diseño de software. Bueno, eso es Screenplay.

Para los que no conozcan SOLID, les cuento que estas clases se diferencian de las Page Object en que son más atómicas, modulares. En lugar de modelar una página, se modela una responsabilidad. Esto es siguiendo el principio de Responsabilidad Única en que cada clase tiene que tener una única...si, adivinaron, responsabilidad. Una clase puede ocuparse de la navegación, otra del procesamiento de datos, otra de armar los requests para API Automation...

Y por eso dije al principio que es algo que no ves tan claro hasta que no empezás a automatizar webservices. Porque en esos casos no van a existir páginas web que modelar, pero si vamos a querer modelar comportamientos de los requests y responses para no tener clases enormes o bien repetir funciones.

En mi opinión, cuando hablamos de UI, siempre me dio la sensación de que para implementar Screenplay de forma exitosa hace falta una madurez del equipo tanto a nivel técnico como de conocimiento profundo y holístico de la aplicación que no se suele encontrar por motivos varios. Uno es que suele haber la suficiente rotación en los equipos para que no se llegue a esa madurez. La otra es que los ingenieros de testing no se preocupen mucho por entender el comportamiento de la aplicación por estar muy ocupados escribiendo código (grave error!). 

Conclusión:

En este post pudimos entender de qué va el Page Object Model (POM para los amigos), para qué se usa, por qué y qué alternativas hay. Si en una pregunta de entrevista te dicen "Se puede implementar POM en API Automation?", ya sabrás cómo responder!

Para aprender a implementarlo en código tienen varios tutoriales completos en Patreon, que pueden empezar hoy mismo y estar creando frameworks robustos en distintos lenguajes y para distintas necesidades! Pasate!

No se olviden también de pasar por el canal de youtube y suscribirse, estoy hablando bastante últimamente por ese medio.

Publicar un comentario

0 Comentarios