TestNG Ouvintes em Selenium
Krishna Degrau
⚡ Resumo Inteligente
Ouvintes em Selenium WebDriver são TestNG Interfaces que interceptam eventos de teste para personalizar logs, relatórios e ações pós-falha. Este artigo explica os métodos de ITestListener e demonstra um exemplo executável. Java exemplo, e esclarece como Selenium A versão 4 substituiu a versão obsoleta WebDriverEventListener.
Selenium Os scripts do WebDriver frequentemente precisam reagir a eventos de teste, como uma asserção bem-sucedida, uma falha de localização ou uma etapa ignorada. Os listeners tornam isso possível. De forma geral, Selenium Os projetos dependem de duas famílias de ouvintes:
- Ouvintes do WebDriver
- TestNG Ouvintes
Neste tutorial, vamos nos concentrar em TestNG Ouvintes, com uma observação sobre como os ouvintes em nível WebDriver mudaram em Selenium 4.x.
O que é um ouvinte em TestNG?
Um Listener é uma interface que modifica o comportamento padrão de TestNGComo o nome sugere, os Listeners “escutam” eventos definidos em um Selenium Você pode criar scripts e reagir de acordo. Para usá-los, implemente a interface Listener relevante e registre-a em sua classe ou conjunto de testes. Os Listeners permitem personalizar o comportamento do usuário. TestNG Gera relatórios, anexa capturas de tela e emite registros estruturados.
Tipos de ouvintes em TestNG
TestNG O sistema fornece uma família de interfaces de ouvinte, cada uma direcionada a um estágio diferente do ciclo de vida de testes.
Abaixo estão os mais usados. TestNG ouvintes:
- IAnnotationTransformador
- IAnotaçãoTransformador2
- IConfigurável
- ICConfiguraçãoListener
- IExecutionListener
- IHookable
- IInvokedMethodListener
- IInvokedMethodListener2
- IMethodInterceptor
- Repórter
- ISSuiteListener
- ITestListener
Essas interfaces são usadas em Selenium para gerar registros ou personalizar TestNG relatórios. Neste tutorial, vamos implementar ITestListener.
ITestListener expõe os seguintes métodos:
- onStart – Chamado quando qualquer teste começa.
- onTestSuccess – Chamado quando um teste é aprovado.
- onTestFailure – Chamado quando um teste falha.
- onTestSkipped – Chamado quando um teste é ignorado.
- onTestFailedButWithinSuccessPercentage – É chamado quando um teste falha, mas está dentro da porcentagem de sucesso.
- onFinish – Chamado após a execução de todos os testes da classe.
Cenário de Teste
Neste cenário de teste, automatizaremos o processo de login e implementaremos ITestListener contra isso.
- Lançamento Firefox e abra o site https://demo.guru99.com/V4/
- Faça login no aplicativo.
Etapas para criar um TestNG Ouvinte
Para o cenário de teste acima, implementaremos o Listener passo a passo.
Passo 1) Crie uma classe chamada Teste de ouvinte que implementa ITestListenerPasse o cursor sobre o sublinhado vermelho e Eclipse Sugeriremos duas soluções rápidas, conforme mostrado abaixo:
Clique em “Adicionar métodos não implementados”. Vários métodos stub (sem corpo) serão adicionados ao seu código, semelhantes a este:
importar org.testng.ITestContext;
importar org.testng.ITestListener;
importar org.testng.ITestResult;
aula pública Teste de ouvinte implementa ITestListener {
@ Override
vazio público onFinish(ITestContext arg0) {
// TODO Esboço de método gerado automaticamente
}
@ Override
vazio público onStart(ITestContext arg0) {
// TODO Esboço de método gerado automaticamente
}
@ Override
vazio público onTestFailedButWithinSuccessPercentage(Resultado do teste arg0) {
// TODO Esboço de método gerado automaticamente
}
@ Override
vazio público onTestFailure(Resultado do teste arg0) {
// TODO Esboço de método gerado automaticamente
}
@ Override
vazio público onTestSkipped(Resultado do teste arg0) {
// TODO Esboço de método gerado automaticamente
}
@ Override
vazio público onTestStart(Resultado do teste arg0) {
// TODO Esboço de método gerado automaticamente
}
@ Override
vazio público onTestSuccess(Resultado do teste arg0) {
// TODO Esboço de método gerado automaticamente
}
}
Agora vamos modificar o Teste de ouvinte classe. Em particular, preencheremos os seguintes métodos: em caso de falha no teste, onTestSkipped, onTestStart e sucesso do teste.
A mudança é simples: cada método imprime o nome do teste para que o console mostre claramente o status de aprovado, reprovado e ignorado.
Após a modificação, o código ficou assim:
importar org.testng.ITestContext;
importar org.testng.ITestListener;
importar org.testng.ITestResult;
aula pública Teste de ouvinte implementa ITestListener {
@ Override
vazio público onFinish(ITestContext Resultado) {
}
@ Override
vazio público onStart(ITestContext Resultado) {
}
@ Override
vazio público onTestFailedButWithinSuccessPercentage(Resultado do teste Resultado) {
}
// Quando um caso de teste falha, este método é chamado.
@ Override
vazio público onTestFailure(Resultado do teste Resultado) {
System.out.println(O nome do caso de teste que falhou é: + Resultado.getName());
}
// Quando um caso de teste é ignorado, este método é chamado.
@ Override
vazio público onTestSkipped(Resultado do teste Resultado) {
System.out.println(O nome do caso de teste ignorado é: + Resultado.getName());
}
// Este método é chamado quando um caso de teste é iniciado.
@ Override
vazio público onTestStart(Resultado do teste Resultado) {
System.out.println(Result.getName() + "Caso de teste iniciado");
}
// Quando um caso de teste é aprovado, este método é chamado.
@ Override
vazio público onTestSuccess(Resultado do teste Resultado) {
System.out.println(O nome do caso de teste aprovado é: + Resultado.getName());
}
}
Passo 2) Crie outra classe chamada Casos de teste para a automação de login. Selenium Esta classe será executada para fazer login no site de demonstração.
importar org.openqa.selenium.By;
importar org.openqa.selenium.WebDriver;
importar org.openqa.selenium.firefox.FirefoxMotoristas;
importar org.testng.Assert;
importar org.testng.annotations.Listeners;
importar org.testng.annotations.Test;
aula pública Casos de teste {
webdriver motorista = new FirefoxDirigir();
// Teste projetado para ser aprovado, para verificar o ouvinte de sucesso.
@Teste
vazio público Conecte-se() {
motorista.obter(“https://demo.guru99.com/V4/”);
driver.findElement(By.name(“uid”)).sendKeys(“mngr34926”);
driver.findElement(By.name("senha")).sendKeys(“amUpenu”);
driver.findElement(By.name(“btnLogin”)).clique();
}
// Teste forçado com falha, para verificar o ouvinte de falhas.
@Teste
vazio público TestarParaFalhar() {
System.out.println(“Este método de teste falhou”);
Assert.assertTrue(falso);
}
}
Passo 3) Em seguida, anexe esse ouvinte à nossa classe de teste. Casos de testeExistem duas maneiras de conectar uma classe a uma interface de ouvinte.
A primeira maneira é usar o @Ouvintes anotação, conforme mostrado abaixo:
Adicionamos esta anotação acima do Casos de teste classe. A classe então fica assim:
importar org.openqa.selenium.By;
importar org.openqa.selenium.WebDriver;
importar org.openqa.selenium.firefox.FirefoxMotoristas;
importar org.testng.Assert;
importar org.testng.annotations.Listeners;
importar org.testng.annotations.Test;
@Listeners(Listener_Demo.ListenerTest.class)
aula pública Casos de teste {
webdriver motorista = new FirefoxDirigir();
// Teste para passar, para verificar o ouvinte de sucesso.
@Teste
vazio público Conecte-se() {
motorista.obter(“https://demo.guru99.com/V4/”);
driver.findElement(By.name(“uid”)).sendKeys(“mngr34926”);
driver.findElement(By.name("senha")).sendKeys(“amUpenu”);
driver.findElement(By.name(“btnLogin”)).clique();
}
// Teste forçado com falha, para verificar o ouvinte de falhas.
@Teste
vazio público TestarParaFalhar() {
System.out.println(“Este método de teste falhou”);
Assert.assertTrue(falso);
}
}
A estrutura do projeto se parece com:
Passo 4) Execute o Casos de teste classe. Métodos dentro Teste de ouvinte são invocadas automaticamente com base no comportamento dos métodos anotados com @Teste.
Passo 5) Verifique a saída exibida no console.
A saída de Casos de teste parece:
C:\Users\gauravn\AppData\Local\Temp\testng-eclipse–1058076918\testng-customsuite.xml
Caso de teste de login iniciado
O nome do caso de teste aprovado é: Login
Caso de teste TestToFail iniciado
Este método de teste falhou
O nome do caso de teste que falhou é: TestToFail
APROVADO: Login
FALHOU: TestToFail
java.lang.AssertionError: esperava-se [true], mas foi encontrado [false]
Utilizando um ouvinte para múltiplas classes
Se um projeto tiver muitas classes de teste, adicionar o @Ouvintes A anotação para cada um deles torna-se trabalhosa e propensa a erros.
Nesse caso, crie um testeng.xml Crie o arquivo e registre o ouvinte lá uma única vez.
Esse ouvinte é então aplicado a todo o conjunto de testes, independentemente do número de classes. Ao executar o arquivo XML, o ouvinte é acionado para cada classe declarada no conjunto, e você pode encadear qualquer número de classes de ouvinte dentro da mesma tag.
WebDriverListener em Selenium 4 em comparação com o EventFiringWebDriver obsoleto
Embora o TestNG Os listeners reagem a eventos do ciclo de vida do teste, enquanto os listeners do WebDriver reagem a ações do driver do navegador, como um clique, uma navegação ou uma chamada findElement. Selenium 3. A abordagem típica era a Ouvinte de evento do WebDriver interface cabeada através de EventFiringWebDriverAmbos estão obsoletos em Selenium 4.x.
O substituto moderno é o Ouvinte do WebDriver interface combinada com Decorador de eventosFiringDecorator:
importar org.openqa.selenium.chrome.ChromeDriver;
importar org.openqa.selenium.support.events.EventFiringDecorator;
importar org.openqa.selenium.support.events.WebDriverListener;
aula pública Ouvinte de registro implementa Ouvinte do WebDriver {
@ Override
vazio público antes deObter(webdriver motorista, URL da string) {
System.out.println(“Navegando até “ + url);
}
}
webdriver bruto = new ChromeDriver();
webdriver motorista = new Decorador de eventosFiringDecorator<>(new LoggingListener()).decorate(raw);
O decorador pode envolver qualquer WebDriver, WebElement ou Alert, o que é mais flexível do que o antigo encapsulador de disparo de eventos. Use Ouvinte do WebDriver para observabilidade do lado do navegador e TestNG ITestListener para geração de relatórios em nível de suíte.
Ouvintes com inteligência artificial: registros mais inteligentes e triagem de falhas.
EQUIPAMENTOS Selenium As equipes estão cada vez mais integrando serviços de IA aos seus sistemas de monitoramento para tornar os sinais de inteligência coletiva mais acionáveis. em caso de falha no testeUm ouvinte com auxílio de IA pode capturar um instantâneo do DOM e uma captura de tela, enviá-los para um modelo que retorna um cluster de causa raiz provável e gravar uma tag de volta no DOM. TestNG relatório ou uma ferramenta como o ReportPortal.
Os padrões comuns orientados por IA incluem:
- Detecção de testes instáveis: Os ouvintes encaminham cronogramas de aprovação/reprovação para um modelo que classifica uma falha como instável, ambiental ou uma regressão real.
- Capturas de tela inteligentes: Os modelos de visão computacional recortam, anotam e comparam capturas de tela da interface do usuário para que os revisores vejam a região alterada em vez de uma página inteira.
- Localizadores com capacidade de autorreparação: A Ouvinte do WebDriver ganchos antesDeEncontrarElemento e pede a um assistente de IA que sugira um localizador alternativo quando o principal falhar. NoSuchElementException.
- Resumos em linguagem natural: An Repórter A implementação alimenta os resultados do conjunto de testes em um LLM (Learning Learning Management) que produz um resumo de um parágrafo para apresentação da reunião.
A camada de ouvinte é o local mais adequado para injetar esses ganchos, pois permanece fora da lógica de teste e se aplica uniformemente em todo o conjunto de testes.
Resumo
Os ouvintes são obrigados a gerar logs ou personalizar TestNG relatórios em Selenium WebDriver.
- TestNG Oferece várias interfaces de ouvinte; escolha aquela que corresponde ao evento que lhe interessa.
- Ouvintes são interfaces usadas em Selenium Scripts do WebDriver para reagir a eventos do ciclo de vida de testes.
- O tutorial demonstrou ITestListener com um teste de aprovação e um teste de reprovação.
- Você pode anexar um ouvinte com @Ouvintes ou registre-o uma vez em testeng.xml para toda a suíte.
- Selenium 4.x substitui EventFiringWebDriver com as Ouvinte do WebDriver + Decorador de eventosFiringDecorator para eventos de nível WebDriver.
