top of page

Qué es el Page Object Model?

Actualizado: 1 mar 2022

Un concepto que vas a escuchar seguido cuando empieces en el mundo de Automation.


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.