El Page Object Model (POM) es un patrón arquitectónico para organizar el código de pruebas automatizadas, especialmente en pruebas de UI. Propone crear clases u objetos separados para representar lógicamente cada página de la aplicación, definiendo métodos para interactuar con los elementos y acciones sobre ellos.
Historia del tema: Anteriormente, las pruebas automatizadas se escribían “como estaban” — interactuando directamente con los localizadores de los elementos en las pruebas mismas, lo que conducía a la duplicación de código y a un mantenimiento complicado. Con la introducción del POM, se hizo posible trasladar todo lo relacionado con una página específica a una clase separada, haciendo que las pruebas automatizadas sean más fáciles de mantener.
Problema: Sin estructurar las pruebas en proyectos grandes, rápidamente se acumula código "desordenado". Cualquier cambio en la interfaz requiere actualizar numerosas pruebas, lo que conlleva un alto costo de mantenimiento.
Solución: El POM permite gestionar de manera centralizada las acciones y elementos, reduce la duplicación y simplifica la escalabilidad de la infraestructura de pruebas. Por ejemplo, si necesita cambiar el localizador de un botón, la modificación se realiza solo en un lugar — en el Page Object, y no en todas las pruebas.
Características clave:
¿Se pueden implementar pruebas automatizadas sin el patrón POM?
Se puede, pero este enfoque llevará a la duplicación de código, altos costos de mantenimiento y a la imposibilidad de escalar.
¿Es obligatorio extraer cada elemento de la página en un Page Object separado?
No, el Page Object se crea para páginas lógicas que incluyen elementos y acciones relacionadas; a veces, para pequeños bloques repetitivos se pueden usar entidades auxiliares separadas (por ejemplo, componentes).
¿El POM resuelve todas las cuestiones arquitectónicas de las pruebas automatizadas?
No, ayuda a estructurar la lógica de trabajo con interfaces, pero no define la arquitectura completa del marco de pruebas — por ejemplo, el manejo de datos, la generación de informes y la gestión del estado de la aplicación.
Las pruebas automatizadas se escribieron sin POM — todas las acciones se especificaron directamente en los métodos de prueba. Como resultado, un simple cambio en el id de un botón en una página requirió la modificación de 35 pruebas, muchas de las cuales se volvieron incorrectas, mientras que otras simplemente dejaron de ejecutarse.
Ventajas:
Desventajas:
En un nuevo proyecto, se construyeron las pruebas según POM: se añadieron clases de páginas, se encapsuló el trabajo con elementos, se utilizó la herencia para patrones comunes.
Ventajas:
Desventajas: