Según su descripción, definitivamente parece que el Modelo de objetos de página junto con los Objetos de página sería el mejor enfoque para un mantenimiento reducido.
Marco de referencia
Framework es como la biblioteca central y no debe depender de la aplicación bajo prueba. Debe ser lo suficientemente genérico como para ejecutar una prueba en cualquier aplicación web.
El marco debe contener los métodos genéricos para actuar sobre los elementos de la página. En otras palabras, el usuario de framework no debería tener que trabajar directamente con el objeto controlador. Framework debería encargarse de proporcionar todos los métodos necesarios para la interacción del usuario.
Un usuario de su marco no debería tener que preocuparse por cómo se abren los navegadores o cómo se produce el clic.
- ¿Hay alguna forma de verificar las estadísticas de mi blog?
- Mi equipo quiere usar el marco Phalcon para construir una aplicación web de red social. ¿Es mejor usar frameworks para construir aplicaciones web en PHP?
- ¿Cuáles son algunos ejemplos de buen diseño de UI / UX para una aplicación web b2b?
- ¿Cómo se clasifica Firebase como competidor de Pusher y PubNub?
- ¿Cuáles son los pros y los contras de crear carpetas individuales para cada usuario en lugar de lanzar todos los archivos cargados en una sola carpeta para una aplicación web?
Modelo de objeto de página
La implementación del modelo de objetos de página no está dentro del marco. Debería estar en su proyecto java que utiliza la biblioteca de marco. Esto reduciría defensivamente el mantenimiento
Repositorio de objetos
Cuando siga el modelo de objeto de página, definirá los localizadores dentro de las páginas. Mantener todos los localizadores de una aplicación en un solo archivo causará problemas de mantenimiento más adelante. Mantener cada uno en su propia clase de página hará que sea mucho más fácil cambiar y depurar.
Crear un proyecto de automatización que respalde todo esto y facilite el mantenimiento lleva tiempo. A mi equipo le llevó alrededor de 1,5 años desarrollar el marco y presentar informes a su estado actual. Hoy, el marco admite la ejecución de alrededor de 35K pruebas por día utilizando alrededor de 2000 máquinas virtuales, cada una con 4 instancias de un navegador. Todavía tenemos un equipo dedicado para codificar los cambios (no usamos excelentes para conducir la prueba). Todo nuestro código está en Java y lo consideramos como un código de producción. Tendrá que seguir ese enfoque para hacer que las pruebas de automatización sean lo suficientemente valiosas e interesantes.
