Padrão de Design COM para Automação com Selenium e Cucumber

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 interface do usuário específicos, como botões, campos de texto, menus suspensos ou outros elementos reutilizáveis.

Neste tutorial, explicaremos 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, manutenção e 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 outros componentes ou páginas. Isso permite alta modularidade e evita a necessidade de modificar páginas inteiras para ajustes pequenos.

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 automaticamente atualizados sem a necessidade de revisitar cada cenário de teste.

4. Adaptado a Interfaces Dinâmicas

Aplicações modernas são frequentemente dinâmicas, com interfaces que mudam com frequência. O COM é ideal para tais aplicações, pois permite testar componentes independentemente da interface. É possível 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 os componentes em classes reutilizáveis, os testadores não precisam redefinir ações para cada página ou componente. Por exemplo, uma definição de um único passo para a ação “clique 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 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 “clique em um botão” ou “insira 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 de 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 executor.

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. Executor

A classe executor é 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 o Cucumber é usar a linguagem Gherkin para escrever cenários de teste. Gherkin permite descrever 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 ele 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 passo 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 recebem 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 “Entrar,” apenas alterando o texto no cenário 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 clicarBotao no ComponenteBotao será utilizado, 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 ButtonComponent usado 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 fáceis de entender, pois estão desacoplados dos detalhes de implementação específicos da página. Você pode focar na interação com os componentes sem se preocupar com a estrutura subjacente da página.
• Facilidade de manutenção: Qualquer modificação em um componente (por exemplo, uma alteração no texto de um 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 de usuário, pois os componentes são independentes uns dos outros. Você pode testar novos componentes ou substituir os existentes sem afetar outros testes.

Quando o Padrão de Design COM é Recomendado?

Este padrão de design é recomendado se a aplicação web a ser testada usar um sistema de design unificado para todos os componentes. Por exemplo, se todos os botões forem declarados da mesma forma, com uma estrutura consistente para todos os elementos da interface do usuário. Nesses casos, usar o 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 Etapas em Vários Produtos

Se você está desenvolvendo e testando vários produtos que usam o mesmo sistema de design, pode criar uma biblioteca que engloba todas as definições de etapas e ações (ou quase todas) para cada componente. Isso permite que os testadores se concentrem apenas em escrever cenários Gherkin, e os testes serão automatizados. Como todos os elementos web são escritos da mesma forma (HTML), componentes como botões, campos de texto e outros elementos de UI se comportarão de forma consistente em todos os projetos.

Como resultado, os testadores não precisam mais repetir as mesmas tarefas — definir definições de etapas e ações para componentes idênticos em vários projetos. Essa abordagem economiza tempo e melhora a manutenibilidade. Se um elemento web for modificado (por exemplo, se o XPath mudar), você só precisa atualizar esse 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 Component Object Model (COM) é um padrão de design poderoso para organizar a automação de testes. Ao focar em componentes reutilizáveis, o COM permite criar testes mais modulares, mantíveis e escaláveis. Esse padrão é particularmente útil para aplicações modernas, onde a interface do usuário muda rapidamente e onde interagir 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.