Modelo de estrutura de teste simples e conveniente no selenide para autotestes da interface do usuário

Olá.

Neste artigo, gostaria de compartilhar minha experiência na automação de testes funcionais. Será sobre escrever uma estrutura de teste conveniente e confiável.

O que vamos usar: Java, Selenide, Alure, TestNG, Maven.



Introdução


Projeto GitHub - SelenideBoilerplate .

Muitas vezes, em artigos sobre automação de testes, os exemplos estão longe da realidade, por exemplo:

driver.get (“URL”)
driver.find_element_by_id(“ID”).send_keys(“username”)
driver.find_element_by_id (“ID”).send_keys(“password”)
driver.find_element_by_id(“submit”).click()

Existem muitos exemplos semelhantes de expectativas, objetos de página etc. Como resultado, pode ser difícil para um testador iniciante organizar tudo de maneira correta e conveniente. O projeto está cheio de muletas, e é por isso que está se tornando cada vez mais difícil escrever novos testes e manter os antigos.

Existem também algumas ferramentas que são muito detalhadas e complicadas demais na minha opinião.

Mostrarei uma estrutura de teste simples, conveniente e facilmente extensível, que é muito mais fácil de trabalhar do que o selênio comum e que usei com sucesso em vários projetos. Este projeto é a base, em projetos reais tudo é um pouco mais complicado (paralelismo, driver remoto, muitos testes etc.).

Ferramentas


  • Selenide é uma biblioteca para escrever testes de interface do usuário de código aberto concisos e estáveis. O Selenide resolve a maioria dos problemas com tempos limite, cliques nos itens que não conseguiram carregar, etc. Você também pode esquecer a StaleElementReferenceException . Uma ferramenta muito conveniente e fácil de aprender, tendo trabalhado com a qual você não deseja mais retornar ao selênio.
  • WebDriverManager - Incluído no Selenide. Uma biblioteca que faz todo o trabalho de baixar drivers para um navegador e definir caminhos de driver -
     System.setProperty("webdriver.browser.driver", "/path_to_driver/driver"); 
  • Fascínio por relatórios.
  • TestNG é uma estrutura de teste.
  • Maven é uma ferramenta para automatizar a montagem de projetos.

Estrutura do projeto




Vamos começar com os módulos de aplicativos e páginas .

Classe PageBuilder


Normalmente, os exemplos fornecem páginas bastante simples, onde tudo se encaixa em uma classe. Mas em projetos reais, pode haver páginas muito grandes, descrevendo todas as funcionalidades das quais em uma classe não é a melhor idéia. Por exemplo, essa poderia ser uma página de recarga com muitas formas de diferentes sistemas de pagamento.

Nesse caso, é melhor dividir a página em várias classes e elementos pares (por exemplo, um produto na cesta) e reunir tudo na classe principal da página.

Portanto, é melhor criar todas as páginas em um único local, principalmente na classe PageBuilder .

package app;

import app.pages.LoginPage;

public class PageBuilder {

    public static LoginPage buildLoginPage() {
        return new LoginPage("/login");
    }

    public static BalancePage buildBalancePage() {
        DepositForm depositForm = new DepositForm();
        WithdrawalForm withdrawalForm = new WithdrawalForm();
        return new BalancePage("/balance", depositForm, withdrawalForm);
    }
}


Classe AppConfig


A classe AppConfig armazena as configurações do aplicativo Web em teste. Por exemplo - o endereço do site, usuários de teste etc. Neste projeto, este é simplesmente o endereço do site.

package app;

public class AppConfig {

    public static final String baseUrl = "https://google.com";

}

Classe de aplicativo


Esta é a classe principal neste módulo. No construtor da classe App , todas as páginas são criadas.

package app;

import app.pages.LoginPage;

public class App {

    public LoginPage loginPage;

    public App() {
        loginPage = PageBuilder.buildLoginPage();
    }
}

Graças a essa abordagem, não é necessário criar constantemente objetos de página em testes, apenas o objeto App é criado a partir do qual as páginas necessárias são obtidas.

Também na classe App podem existir métodos como - registro, registro e criação de pedidos, etc.

Ou seja, grandes operações nas quais vários objetos de página estão envolvidos e que geralmente são necessários em testes.

Vamos para os objetos da página


Graças ao Selenide, é fácil trabalhar com objetos de página. Todas as páginas são herdadas da classe base BasePage . A URL da página relativa é passada para o construtor do objeto de página.

Todos os elementos da página possuem um modificador de acesso público , para que você possa escrever testes nos estilos imperativo e declarativo. Além disso, a partir dos elementos, você pode obter os dados necessários, como texto ou algum atributo.

O localizador é armazenado em apenas um local. Toda a lógica da página deve ser descrita nos métodos de página.

Com essa abordagem, se algo quebrar ou mudar, na maioria dos casos não é necessário reescrever os testes, o método é finalizado ou o localizador muda para o real.


package app.pages;

import com.codeborne.selenide.SelenideElement;
import helpers.Driver;
import static com.codeborne.selenide.Selenide.*;

public class LoginPage extends BasePage {

    public SelenideElement loginField = $("#login__username");
    public SelenideElement passwordField = $("#login__password");
    public SelenideElement signInButton = $("#login_enter");
    public SelenideElement termsOfUseLabel = $("label[for=\"login_agree\"]");

    public LoginPage(String pageUrl) {
        super(pageUrl);
    }
    
    public void login(String email, String password) {
        loginField.setValue(email);
        passwordField.setValue(password);
        termsOfUseLabel.click();
        signInButton.click();
        Driver.waitForUrlContains("account/accounts");
    }
}


Descansar


O módulo auxiliar contém duas classes importantes:

TestConfig - Nesta classe, você pode obter as configurações com as quais os testes são executados. As configurações padrão também são mostradas aqui.

Os testes são executados pelo comando.Os mvn test -Dbrowser=chrome -Dheadless=1

valores das variáveis ​​são obtidos na linha de comando e, graças à classe TestConfig, estão disponíveis nos testes e no aplicativo.

Por exemplo, você pode alterar o URL do aplicativo dependendo do ambiente (desenvolvedor, estágio, produção).


package helpers;

public class TestConfig {

    public static String browser = "chrome";
    public static String headless = "1";

    public static void initConfig() {
        browser = System.getProperty("browser") == null ? "chrome" : System.getProperty("browser");
        headless = System.getProperty("headless") == null ? "1" : System.getProperty("headless");
    }

    public static boolean isHeadless() {
        return headless.contains("1");
    }
}

A classe Driver é o meu invólucro de drivers de selênio e seleneto com alguns métodos úteis.

Os métodos mais importantes:

Driver.initDriver () - aqui o driver / navegador é inicializado.

   public static void initDriver() {

        // Get settings from command line

        TestConfig.initConfig();

        // Set settings for selenide browser

        Configuration.pageLoadStrategy = "eager";
        Configuration.browserSize = "1920x1080";
        Configuration.holdBrowserOpen = false;
        Configuration.screenshots = false;

        if(TestConfig.isHeadless()) {
            Configuration.headless = true;
        } else {
            Configuration.headless = false;
        }

        switch (TestConfig.browser) {
            case "chrome":
                Configuration.browser = Browsers.CHROME;
                break;
            case "firefox":
                Configuration.browser = Browsers.FIREFOX;
                break;
            default:
                Configuration.browser = Browsers.CHROME;
                break;
        }
    }

Driver.clearCookies()
Driver.close()

Testes


Todas as classes de teste são herdadas da classe A_BaseTest , na qual o objeto do aplicativo App é criado , logger , softAssert , o navegador abre e fecha, os cookies são limpos após cada teste.

Há também um A_BaseTestListener onde os erros podem ser registrados.

Os testes são mais ou menos assim. Fácil de ler, fácil de manter.

import org.testng.annotations.Test;

public class ExampleTest extends A_BaseTest
{
    @Test
    public void loginViaEmail() {
        app.loginPage.open();
        app.loginPage.login("email@email.com", "passwords");
        
        logger.info("Sample info message");
               
        softAssert.assertEquals(2,2);
        softAssert.assertAll();
    }
}

As classes de teste são especificadas em testng.xml .

A pasta teste-saída contém logs e capturas de tela - Driver.takeScreenshot () .

Para relatórios, o Allure é usado . Após a conclusão dos testes, você pode executar o comando allure serve target/allure-resultse ver o relatório.

Projeto GitHub - SelenideBoilerplate

All Articles