O Component Object Model (COM) é um padrão de design que permite estruturar testes em projetos de automação de testes. Inspirado no popular Modelo de Objeto de Página (POM), o COM vai além de lidar com páginas inteiras e foca em componentes de UI específicos, como botões, campos de texto, menus suspensos ou outros elementos reutilizáveis.
Neste tutorial, vamos explicar como implementar o COM para testar uma aplicação web com Selenium WebDriver e Cucumber e como essa abordagem pode tornar seus testes mais flexíveis, modulares e fáceis de manter.
O Que É o Component Object Model?
O Component Object Model (COM) é uma evolução do modelo POM. Em vez de modelar uma página inteira como um objeto com métodos interagindo com todos os elementos da página, o COM quebra a interface do usuário em componentes individuais, como:
- Botões
- Campos de texto
- Menus suspensos
- Barras de pesquisa
- Tabelas
Cada componente é encapsulado em uma classe Java, e suas interações são gerenciadas por métodos específicos, permitindo que cada elemento seja mantido e testado de forma independente. Isso melhora a reutilização de código, a manutenção e a flexibilidade nos testes.
Por Que Usar COM em Vez de POM?
1. Maior Modularidade
Com COM, cada componente (como um botão ou campo de texto) é uma entidade independente. Se um componente muda (por exemplo, o texto de um botão muda), você só precisa modificar a classe do componente sem afetar os outros componentes ou páginas. Isso permite alta modularidade e evita a necessidade de modificar páginas inteiras para ajustes mínimos.
2. Reutilização e Flexibilidade
Componentes podem ser reutilizados em várias páginas da aplicação, reduzindo a duplicação de código. Por exemplo, um ButtonComponent pode ser usado em qualquer página onde o botão aparece, reduzindo a redundância e aumentando a flexibilidade nos testes.
3. Manutenção Simplificada
A manutenção é mais fácil com COM. Se um componente muda (por exemplo, um botão ou campo de texto), você só precisa modificar a classe que representa esse componente. Todos os testes que usam esse componente serão atualizados automaticamente sem a necessidade de revisitar cada cenário de teste.
4. Adaptado a Interfaces Dinâmicas
As aplicações modernas são frequentemente dinâmicas, com interfaces que mudam frequentemente. COM é ideal para tais aplicações porque permite testar componentes independentemente da interface. Você pode modificar ou adicionar componentes sem afetar os testes de outras partes da aplicação.
5. Automação de Testes Mais Rápida
O COM acelera a automação de testes. Ao centralizar as interações com componentes em classes reutilizáveis, os testadores não precisam redefinir ações para cada página ou componente. Por exemplo, uma definição em um único passo para a ação “clicar em um botão” pode ser usada em todos os testes do projeto, reduzindo significativamente o tempo necessário para automatizar os testes.
6. Evitando a Repetição de Trabalho entre Testadores
Com o COM, os testadores não precisam mais repetir o mesmo trabalho para cada teste. Definições de passos centralizadas para ações comuns, como “clicar em um botão” ou “inserir texto”, podem ser usadas por todos os testadores no projeto. Isso garante consistência nos testes, evitando repetições desnecessárias, melhorando a eficiência e a colaboração entre os testadores.
Arquitetura do Projeto COM
A arquitetura de um projeto baseado em COM é estruturada em torno de três elementos principais: componentes, definições de passos e o executador.
1. Componentes
Cada componente representa um elemento de IU, como um botão, campo de texto ou menu suspenso. Essas classes encapsulam todas as interações possíveis com o elemento.
Aqui está um exemplo da classe 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. Definições de Etapas
Definições de etapas vinculam as etapas definidas nos arquivos Gherkin aos métodos nos componentes. Eles são responsáveis por interagir com os componentes e implementar as ações especificadas no cenário de teste.
Aqui está um exemplo 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
A classe runner é responsável por executar os testes usando JUnit ou TestNG. Ela configura o Cucumber para carregar os cenários de teste definidos nos arquivos .feature e executá-los usando as definições de etapas.
Aqui está um exemplo 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 {
}
Escrevendo e Explicando um Cenário Gherkin
Um dos elementos essenciais da automação com Cucumber é usar a linguagem Gherkin para escrever cenários de teste. O Gherkin permite que você descreva testes de forma legível e compreensível, mesmo para pessoas não técnicas.
Vamos considerar um cenário em que queremos testar a interação com um botão usando o ButtonComponent que definimos anteriormente. Aqui está como poderia ser escrito em 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
Explicação do Cenário
Cenário
Este cenário descreve a ação em que um usuário clica no botão ‘Enviar’ na página de login e garante que seja redirecionado para a página inicial após o clique.
- Dado que estou na página de login: O estado inicial do teste é que o usuário está na página de login.
- Quando eu clico no botão “Enviar“: A ação realizada no teste é clicar no botão ‘Enviar’.
- Então, devo ser redirecionado para a página inicial: A verificação esperada é que o usuário seja redirecionado para a página inicial após clicar no botão.
Link Com COM
Cada etapa deste cenário é mapeada para uma definição de etapa em ButtonStepDefinition, onde a ação de clique é tratada pelo ButtonComponent, tornando o teste modular e fácil de manter.
Explicação Adicional
Observe que os passos levam o texto exibido nos botões (ou espaços reservados em campos de entrada, etc.) como parâmetros. Isso torna os cenários mais legíveis e genéricos. Por exemplo, no cenário acima, o texto do botão “Enviar” é usado diretamente no passo “Quando eu clico no botão ‘Enviar.’” Dessa forma, a mesma definição de passo pode ser reutilizada para testar outro botão, como “Login,” simplesmente alterando o texto no cenário em Gherkin. Isso melhora a reutilização do código de teste, tornando os cenários mais intuitivos e flexíveis.
Reutilização de Passos com COM
Uma das principais vantagens do COM é a reutilização de definições de passos para diferentes botões. Por exemplo, o mesmo passo Quando eu clico no botão {string} pode ser usado para todos os botões, independentemente do texto exibido no botão. A abordagem COM permite que você parametrize dinamicamente a ação de clique com base no texto do botão.
Vamos considerar outro cenário com um botão diferente:
Cenário
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
Em ambos os casos, o mesmo método cliqueNoBotao no ComponenteBotão será usado, mas o texto do botão mudará dependendo do cenário. Isso demonstra como o COM permite reutilizar o mesmo componente e definição de passo, tornando os testes flexíveis e modulares.
Como o COM Melhora a Automação de Testes
O COM melhora a automação de testes de várias maneiras:
- Redução da duplicação de código: Ao usar componentes reutilizáveis, você reduz a duplicação de código nos testes. Por exemplo, um
ButtonComponentusado em várias páginas da aplicação elimina a necessidade de escrever testes repetitivos. - Testes mais legíveis e modificáveis: Os testes são mais claros e mais fáceis de entender, pois estão desacoplados dos detalhes de implementação específicos da página. Você pode se concentrar em interagir com os componentes sem se preocupar com a estrutura da página subjacente.
- Facilidade de manutenção: Qualquer modificação em um componente (por exemplo, uma alteração no texto do botão) afeta apenas a classe do componente, não os testes. Isso torna a manutenção muito mais simples e rápida.
- Testes mais flexíveis: Os testes podem ser facilmente adaptados a mudanças nas interfaces do usuário, pois os componentes são independentes entre si. Você pode testar novos componentes ou substituir os existentes sem afetar outros testes.
Quando o Padrão de Projeto COM é Recomendado?
Este padrão de projeto é recomendado se a aplicação web sendo testada usa um sistema de design unificado para todos os componentes. Por exemplo, se todos os botões são declarados da mesma forma, com uma estrutura consistente para todos os elementos de IU. Em tais casos, o uso do COM permite centralizar as interações com cada tipo de componente (como botões, campos de texto, etc.), tornando os testes mais modulares, reutilizáveis e mais fáceis de manter.
Reutilizando Definições de Passos em Múltiplos Produtos
Se você está desenvolvendo e testando múltiplos produtos que utilizam o mesmo sistema de design, você pode criar uma biblioteca que abranja todas as definições de passos e ações (ou quase todas) para cada componente. Isso permite que os testadores se concentrem exclusivamente na escrita de cenários em Gherkin, e os testes serão automatizados. Como todos os elementos da web são escritos da mesma forma (HTML), componentes como botões, campos de texto e outros elementos de interface do usuário se comportarão de maneira consistente em todos os projetos.
Como resultado, os testadores não precisam mais repetir as mesmas tarefas — definindo definições de passos e ações para componentes idênticos em múltiplos projetos. Essa abordagem economiza tempo e melhora a manutenibilidade. Se um elemento da web for modificado (por exemplo, se o XPath mudar), você só precisa atualizar aquele elemento na biblioteca compartilhada, e a modificação será aplicada automaticamente a todos os projetos de automação. Isso reduz o risco de erros e torna as atualizações mais eficientes em diferentes produtos.
Conclusão
O Modelo de Objeto Componente (COM) é um padrão de design poderoso para organizar a automação de testes. Ao focar em componentes reutilizáveis, o COM permite que você crie testes mais modulares, manuteníveis e escaláveis. Esse padrão é particularmente útil para aplicações modernas, onde a interface do usuário muda rapidamente e onde a interação com componentes independentes é essencial.
Com testes reutilizáveis, manutenção simplificada e uma arquitetura flexível, COM é a solução ideal para automação de testes em projetos Selenium e Cucumber.
Source:
https://dzone.com/articles/com-design-pattern-selenium-and-cucumber