El Modelo de Objeto de Componente (COM) es un patrón de diseño que te permite estructurar pruebas en proyectos de automatización de pruebas. Inspirado en el popular Modelo de Objeto de Página (POM), el COM va más allá de manejar páginas completas y se centra en componentes de la interfaz de usuario específicos, como botones, campos de texto, menús desplegables u otros elementos reutilizables.
En este tutorial, explicaremos cómo implementar COM para probar una aplicación web con Selenium WebDriver y Cucumber y cómo este enfoque puede hacer que tus pruebas sean más flexibles, modulares y fáciles de mantener.
¿Qué es el Modelo de Objeto de Componente?
El Modelo de Objeto de Componente (COM) es una evolución del modelo POM. En lugar de modelar una página entera como un objeto con métodos que interactúan con todos los elementos de la página, el COM divide la interfaz de usuario en componentes individuales, tales como:
- Botones
- Campos de texto
- Menús desplegables
- Barras de búsqueda
- Tablas
Cada componente está encapsulado en una clase Java, y sus interacciones son gestionadas por métodos específicos, lo que permite que cada elemento sea mantenido y probado de forma independiente. Esto mejora la reutilización de código, el mantenimiento y la flexibilidad en las pruebas.
¿Por qué usar COM en lugar de POM?
1. Mayor Modularidad
Con COM, cada componente (como un botón o campo de texto) es una entidad independiente. Si un componente cambia (por ejemplo, cambia el texto de un botón), solo necesitas modificar la clase del componente sin afectar a otros componentes o páginas. Esto permite una alta modularidad y evita la necesidad de modificar páginas enteras para ajustes menores.
2. Reutilización y Flexibilidad
Los componentes pueden ser reutilizados en múltiples páginas de la aplicación, reduciendo la duplicación de código. Por ejemplo, un ButtonComponent puede ser utilizado en cualquier página donde aparezca el botón, reduciendo la redundancia y aumentando la flexibilidad de las pruebas.
3. Mantenimiento Simplificado
El mantenimiento es más fácil con COM. Si un componente cambia (por ejemplo, un botón o campo de texto), solo necesitas modificar la clase que representa ese componente. Todas las pruebas que utilizan ese componente se actualizarán automáticamente sin necesidad de revisar cada escenario de prueba.
4. Adaptado a Interfaces Dinámicas
Las aplicaciones modernas suelen ser dinámicas, con interfaces que cambian con frecuencia. COM es ideal para este tipo de aplicaciones porque permite probar componentes de forma independiente de la interfaz. Puedes modificar o añadir componentes sin afectar las pruebas de otras partes de la aplicación.
5. Automatización de pruebas más rápida
COM acelera la automatización de pruebas. Al centralizar las interacciones con componentes en clases reutilizables, los probadores no necesitan definir acciones para cada página o componente. Por ejemplo, una definición de un solo paso para la acción “hacer clic en un botón” se puede utilizar en todas las pruebas del proyecto, reduciendo significativamente el tiempo necesario para automatizar las pruebas.
6. Evitar la repetición de trabajo entre probadores
Con COM, los probadores ya no necesitan repetir el mismo trabajo para cada prueba. Las definiciones de pasos centralizadas para acciones comunes, como “hacer clic en un botón” o “introducir texto”, pueden ser utilizadas por todos los probadores en el proyecto. Esto garantiza la consistencia en las pruebas, evitando repeticiones innecesarias, mejorando la eficiencia y la colaboración entre los probadores.
Arquitectura de Proyecto COM
La arquitectura de un proyecto basado en COM está estructurada alrededor de tres elementos principales: componentes, definiciones de pasos y el ejecutor.
1. Componentes
Cada componente representa un elemento de la interfaz de usuario, como un botón, un campo de texto o un menú desplegable. Estas clases encapsulan todas las interacciones posibles con el elemento.
Aquí tienes un ejemplo de la clase ButtonComponent:
public class ButtonComponent {
private WebDriver driver;
public ButtonComponent(WebDriver driver) {
this.driver = driver;
}
public void clickButton(String buttonText) {
WebElement button = driver.findElement(By.xpath("//button[text()='" + buttonText + "']"));
button.click();
}
}
2. Definiciones de pasos
Las definiciones de pasos vinculan los pasos definidos en los archivos Gherkin con los métodos en los componentes. Son responsables de interactuar con los componentes e implementar las acciones especificadas en el escenario de prueba.
Aquí tienes un ejemplo de ButtonStepDefinition:
public class ButtonStepDefinition {
private ButtonComponent buttonComponent;
public ButtonStepDefinition(WebDriver driver) {
this.buttonComponent = new ButtonComponent(driver);
}
@When("I click on the button {string}")
public void iClickOnTheButton(String buttonText) {
buttonComponent.clickButton(buttonText);
}
}
3. Runner
La clase runner es responsable de ejecutar las pruebas utilizando JUnit o TestNG. Configura Cucumber para cargar los escenarios de prueba definidos en los archivos .feature y ejecutarlos utilizando las definiciones de pasos.
Aquí tienes un ejemplo de TestRunner:
@RunWith(Cucumber.class)
@CucumberOptions(
features = "src/test/resources/features",
glue = "com.componentObjectModel.stepDefinitions",
plugin = {"pretty", "html:target/cucumber-reports.html"}
)
public class TestRunner {
}
Escribir y explicar un escenario Gherkin
Uno de los elementos esenciales de la automatización con Cucumber es utilizar el lenguaje Gherkin para escribir escenarios de prueba. Gherkin te permite describir pruebas de una manera legible y comprensible, incluso para personas no técnicas.
Consideremos un escenario donde queremos probar la interacción con un botón utilizando el ButtonComponent que definimos anteriormente. Así es como podría estar escrito en Gherkin:
Scenario: User clicks on the "Submit" button Given I am on the login page When I click on the button "Submit" Then I should be redirected to the homepage
Explicación del Escenario
Escenario
Este escenario describe la acción en la que un usuario hace clic en el botón ‘Enviar’ en la página de inicio de sesión y se asegura de que sea redirigido a la página de inicio después de hacer clic.
- Dado que estoy en la página de inicio de sesión: El estado inicial de la prueba es que el usuario se encuentra en la página de inicio de sesión.
- Cuando hago clic en el botón “Enviar”“: La acción realizada en la prueba es hacer clic en el botón ‘Enviar’.
- Entonces, debería ser redirigido a la página de inicio: La verificación esperada es que el usuario sea redirigido a la página de inicio después de hacer clic en el botón.
Enlace con COM
Cada paso en este escenario está mapeado a una definición de paso en ButtonStepDefinition, donde la acción de clic es manejada por el ButtonComponent, haciendo que la prueba sea modular y fácil de mantener.
Explicación Adicional
Nota que los pasos toman el texto mostrado en los botones (o marcadores de posición en campos de entrada, etc.) como parámetros. Esto hace que los escenarios sean más legibles y genéricos. Por ejemplo, en el escenario anterior, el texto del botón “Enviar” se utiliza directamente en el paso “Cuando hago clic en el botón ‘Enviar.’” De esta manera, la misma definición de paso podría reutilizarse para probar otro botón, como “Iniciar sesión,” simplemente cambiando el texto en el escenario de Gherkin. Esto mejora la reutilización del código de prueba al mismo tiempo que hace que los escenarios sean más intuitivos y flexibles.
Reutilización de Pasos con COM
Una de las principales ventajas de COM es la reutilización de las definiciones de pasos para diferentes botones. Por ejemplo, el mismo paso Cuando hago clic en el botón {string} se puede usar para todos los botones, independientemente del texto mostrado en el botón. El enfoque de COM te permite parametrizar dinámicamente la acción de clic en función del texto del botón.
Consideremos otro escenario con un botón diferente:
Escenario
User clicks on the "Login" button
Given I am on the login page
When I click on the button "Login"
Then, I should be redirected to the dashboard
En ambos casos, se utilizará el mismo método clickButton en el ButtonComponent, pero el texto del botón cambiará según el escenario. Esto demuestra cómo COM permite reutilizar el mismo componente y definición de paso, haciendo que las pruebas sean flexibles y modulares.
Cómo COM Mejora la Automatización de Pruebas
COM mejora la automatización de pruebas de varias formas:
- Reducción de la duplicación de código: Al utilizar componentes reutilizables, se reduce la duplicación de código en las pruebas. Por ejemplo, un
ButtonComponentutilizado en múltiples páginas de la aplicación elimina la necesidad de escribir pruebas repetitivas. - Pruebas más legibles y modificables: Las pruebas son más claras y fáciles de entender al estar desacopladas de los detalles de implementación específicos de la página. Puedes concentrarte en interactuar con los componentes sin preocuparte por la estructura subyacente de la página.
- Facilidad de mantenimiento: Cualquier modificación a un componente (por ejemplo, un cambio en el texto de un botón) solo afecta a la clase del componente, no a las pruebas. Esto hace que el mantenimiento sea mucho más simple y rápido.
- Pruebas más flexibles: Las pruebas pueden adaptarse fácilmente a cambios en las interfaces de usuario, ya que los componentes son independientes entre sí. Puedes probar nuevos componentes o reemplazar los existentes sin afectar a otras pruebas.
¿Cuándo se recomienda el patrón de diseño COM?
Este patrón de diseño se recomienda si la aplicación web que se está probando utiliza un sistema de diseño unificado para todos los componentes. Por ejemplo, si todos los botones se declaran de la misma manera, con una estructura consistente para todos los elementos de la interfaz de usuario. En tales casos, el uso de COM te permite centralizar las interacciones con cada tipo de componente (como botones, campos de texto, etc.), haciendo que las pruebas sean más modulares, reutilizables y fáciles de mantener.
Reutilizando Definiciones de Pasos en Varios Productos
Si estás desarrollando y probando múltiples productos que utilizan el mismo sistema de diseño, puedes crear una biblioteca que abarque todas las definiciones de pasos y acciones (o casi todas) para cada componente. Esto permite a los probadores enfocarse únicamente en escribir escenarios Gherkin, y las pruebas serán automatizadas. Dado que todos los elementos web están escritos de la misma manera (HTML), componentes como botones, campos de texto y otros elementos de la interfaz de usuario se comportarán de manera consistente en todos los proyectos.
Como resultado, los probadores ya no necesitan repetir las mismas tareas, como definir definiciones de pasos y acciones para componentes idénticos en múltiples proyectos. Este enfoque ahorra tiempo y mejora la mantenibilidad. Si un elemento web es modificado (por ejemplo, si cambia el XPath), solo necesitas actualizar ese elemento en la biblioteca compartida, y la modificación se aplicará automáticamente a todos los proyectos de automatización. Esto reduce el riesgo de errores y hace que las actualizaciones sean más eficientes en diferentes productos.
Conclusión
El Modelo de Objeto de Componente (COM) es un patrón de diseño poderoso para organizar la automatización de pruebas. Al centrarse en componentes reutilizables, COM te permite crear pruebas más modulares, mantenibles y escalables. Este patrón es particularmente útil para aplicaciones modernas, donde la interfaz de usuario cambia rápidamente y donde interactuar con componentes independientes es esencial.
Con pruebas reutilizables, mantenimiento simplificado y una arquitectura flexible, COM es la solución ideal para la automatización de pruebas en proyectos de Selenium y Cucumber.
Source:
https://dzone.com/articles/com-design-pattern-selenium-and-cucumber