DEV Community: Tarcisio C. Uchoa

Organização de testes automatizados

Tarcisio C. Uchoa — Mon, 10 Feb 2025 18:19:20 +0000

Uma vez que você determinou que está no negócio dos testes automatizados no navegador, está com seu ambiente Playwright pronto para começar a escrever os testes, você vai geralmente executar uma combinação de três passos:

Configurar os dados
Executar um conjunto discreto de ações
Avaliar os resultados

E você deverá manter esses passos os mais curtos possível; uma ou duas operações devem ser suficientes maioria das vezes.

Arrange, Act and Assert (AAA) pattern

Ref: Paulo Gomes: Unit Testing and the Arrange, Act and Assert (AAA) Pattern

O padrão AAA (Arrange-Act-Assert) tornou-se quase um padrão em todo o setor. Ele sugere que você divida seu método de teste em três seções: organizar, agir e afirmar. Cada um deles é responsável apenas pela parte em que recebe o nome.

Portanto, na seção de organização (Arrange), você só tem o código necessário para configurar esse teste específico. Aqui, os objetos seriam criados, a configuração dos mocks (se você estiver usando um) e as expectativas potencialmente definidas. Depois, há a Ação (Act), que deve ser a invocação do método que está sendo testado. E no Assert você simplesmente verificaria se as expectativas foram atendidas.

Seguir esse padrão torna o código bem estruturado e fácil de entender. Em linhas gerais, ficaria assim:

// arrange
const homePage = new HomePage(page, BASE_URL);

// act
await homePage.navigate();

// assert
await expect(homePage.title).toBeVisible();

Exemplo

Larry criou um site que permite que os usuários comprem unicórnios personalizados. O fluxo geral ("caminho feliz") seria algo semelhante a isso:

Criar uma conta
Configurar o unicórnio
Adicionar ao carrinho de compras
Verificar e pagar
Dar feedback sobre o unicórnio

Em vez de um roteiro de teste que envolva todas as etapas, separar em testes independentes e rápidos.

Se precisarmos testar apenas o "configurar o unicórnio", vamos precisar da primeira etapa "criar uma conta", mas não estamos testando a criação de conta.

Criar a conta (independente se vai usar uma conta existente ou criar uma nova ou criar uma conta de administrador...) deve fazer parte do "configurar os dados".

A fase de configuração (arrange) pode ser incluída com apenas uma ou duas linhas de código:

/*
Crie um usuário que tenha permissões somente leitura.
eles podem configurar um unicórnio, mas eles não têm
informações de pagamento configuradas,
nem têm privilégios administrativos
No momento em que o usuário é criado, seu endereço
de e-mail e senha são gerados aleatoriamente
você nem precisa conhecê-los.
*/ 
let user = await userFactory.createCommonUser ();
// Esse método foi criado em outro lugar

/*
Faça login como este usuário.
O login neste site leva você à sua página pessoal
"Minha conta", e então o objeto AccountPage
é retornado pelo método loginAs, permitindo que
você execute ações da AccountPage.
*/
let accountPage = await loginAs(user.email, user.password);

A userFactory pode ser estendida para criar usuários administrativos ou outros tipos, retornando dados necessários para uso, como login, nome, e-mail, senha...

Estamos usando o padrão Page Object Model (POM) neste caso.

A utilização desses métodos, fora do teste de "configurar unicórnio" não deve atrapalhar/distrair o teste em si.

Os testes devem ser compostos de ações, realizadas do ponto de vista do usuário, dentro do contexto das páginas do site. Essas páginas são armazenadas como objetos com informações específicas sobre como a página é composta e como as ações são realizadas.

O testador deve se preocupar com o objetivo do teste: que tipo de unicórnio? Rosa ou roxo? Com óculos escuros? Tatuagem?

E o teste ainda não precisa pensar em botões, campos, menus, formulários. Escrever o código como o usuário tentando resolver o problema. Fase de ação (executa rum conjunto discreto de ações):

/*
O Unicórnio é um objeto de nível superior - ele possui atributos,
que são definidos aqui. Isso armazena apenas os valores;
não preenche formulários da web nem interage com o navegador
de qualquer forma.
*/
let sparkles = new Unicorn(
    "Sparkles",
    UnicornColors.PURPLE,
    UnicornAccessories.SUNGLASSES,
    UnicornAdornments.STAR_TATTOOS);

/*
Uma vez que já estamos "na" página da conta,
temos que usá-la para chegar ao lugar real onde
você configura os unicórnios. Chamar o método
"Add Unicorn" nos leva lá.
*/
let addUnicornPage = await accountPage.addUnicorn();

/*
Agora que estamos na AddUnicornPage, passaremos o objeto
"sparkles" para o método createUnicorn().
Este método pegará os atributos do Sparkles,
preencher o formulário e clicar em enviar.
*/
let unicornConfirmationPage = await addUnicornPage.createUnicorn(sparkles);

Agora com o unicórnio configurado, etapa 3 (assert): certificar-se de que funcionou:

/*
O método exists() de UnicornConfirmationPage
pegará o objeto Sparkles - uma especificação
dos atributos que você deseja ver e compará-los
com os campos na página
*/
await expect(unicornConfirmationPage(sparkles)).toBeVisible();

Sem botões, localizadores, controles de navegador. Este método de modelagem mantém os testes imutáveis. Se a lógica por trás disso alterar (posição dos botões, uso de framework diferente), o teste continua válido.

Os objetos de página é que precisarão de alterações nesses casos de redesenho do site, mas os testes permanecerão os mesmos.

Page Object Model (POM)

Ref: Selenium: Page Object Models
Ref: Danilo José: POM (Page Object Model design pattern)
Ref: Playwright: Page Object Models

De acordo com o padrão Page Object Model, devemos manter nossos testes e localizadores de elementos separados, usando um conceito de código limpo para facilitar o entendimento e a manutenção.

Em geral, os casos de teste são otimizados, pois podem usar métodos de objeto de página em classes POM. Isso significa que quaisquer mudanças na interface do usuário podem ser facilmente implementadas, atualizadas ou mantidas dentro dos objetos de página e classes.

Outra característica importante é que há uma separação clara entre o código de teste e o código específico da página, como localizadores e layout, tornando o código muito mais fácil de manter. Em outras palavras, isso faz com que alterações de código sejam necessárias apenas nas classes de objeto de página quando houver uma alteração na interface do usuário, conforme mencionado anteriormente, reduzindo também a duplicação de código.

Um objeto de página é uma classe orientada a objeto que serve como uma interface para uma página de teste de automação. Os testes usam os métodos dessa classe de objeto de página sempre que precisam interagir com a interface do usuário dessa página.

Outra vantagem é que há um único repositório para os serviços de operações oferecidos pela página, em vez de ter esses serviços espalhados pelos testes (teste de login aponta para o cabeçalho da home, teste de logout aponta para o cabeçalho da home, teste de navegação aponta para o cabeçalho na home...). Quaisquer alterações necessárias devido a alterações na interface do usuário são feitas em um só lugar.

Implementação (com Playwright)

Vamos criar uma classe HomePage para encapsular elementos e operações comuns da homepage do projeto:

// page-objects/HomePage.ts

import { Page, Locator } from '@playwright/test';

export default class HomePage {
    readonly page: Page;
    readonly baseUrl: string;
    readonly mainContent: Locator;
    readonly cardContact: Locator;

    constructor(page: Page, baseUrl: string) {
        this.page = page;
        this.baseUrl = baseUrl;
        this.mainContent = page.locator('data-test=main-content');
        this.cardContact = page.locator('data-test=card-contact');
    }

    async navigate(): Promise<void>{
        const url = await this.page.url();
        if (url != this.baseUrl) {
            await this.page.goto(this.baseUrl);
        }    
        await this.page.waitForLoadState('networkidle');
    }
}

Agora importamos a classe HomePage no nosso teste:

// HomePageExample.spec.ts

import { expect, test} from '@playwright/test';
import { HomePage } from './page-objects/HomePage';

test('Home Page should be successfully loaded', async ({page}) => {
    cont BASE_URL = 'https://meuprojeto.com.br';
    const homePage = new HomePage(page, BASE_URL);

    // using HomePage class method to navigate
    await homePage.navigate();

    const pageTitle = await page.title();
    await expect(pageTitle).toBe('Meu Projeto');
    await expect(page.url()).toBe(BASE_URL);

    // using HomePage class locators
    await expect(homePage.mainContent).toBeVisible();
    await expect(homePage.cardContact).toBeVisible();
});

Se outros testes precisarem usar elementos da Homepage, eles podem chamar a classe HomePage e usar seus métodos e localizadores.

Se a interface do usuário for alterada, o testador só precisa alterar os localizadores na classe auxiliar e não em várias linhas em vários testes diferentes.

Regras para objetos de página

Os próprios objetos de página nunca devem fazer asserções, verificações ou afirmações. Isso é parte do teste e deve estar no código de teste. O objeto de página conterá a representação da página, os serviços que a página fornece por meio de métodos. Nenhum código que está sendo testado deve estar dentro do objeto de página.

Evitar coisas como:

await homePage.verifySearchIsVisible();

...deixando a asserção com o método verifySearchIsVisible() do objeto de página homePage.

Idealmente a homePage pode retornar o Search input e o teste faz a asserção se ele está visível:

await expect(homePage.searchInput).toBeVisible();

Se a entrada de pesquisa for alterada, o testador precisará alterar apenas a classe que manipula a entrada e não todos os testes que usam essa classe.

Há uma única verificação que pode e deve ser feita dentro do Objeto de Página: verificar se a página, e possivelmente elementos críticos da página, foram carregados corretamente. Esta verificação deve ser fei enquanto instanciar o objeto de página.

Um objeto de página não precisa necessariamente representar todas as partes da própria página. Os mesmos princípios de objeto de página devem ser usados para "objetos de componente de página", que representam partes da página que podem ser incluídas em objetos de página ou testes.

Um objeto de página pode incluir vários objetos de componente, e cada objeto de componente de página tem seus próprios métodos para utilizar a funcionalidade a que serve, como uma barra de navegação, uma caixa de pesquisa, um cabeçalho ou rodapé (aninhando objetos de componente dentro de outros objetos de componente para mais páginas complexas ou a objetos que são usados em todo o site), melhorando a manutenção e reduzindo a duplicação de código.

Série de artigos sobre E2E:

Playwright: dicas e boas práticas

Tarcisio C. Uchoa — Mon, 10 Feb 2025 18:10:16 +0000

Priorizar atributos que o usuário interage (user-facing)

Um usuário não sabe o que são ids ou classes e não procuram esses itens na hora de interagir com a página.

O teste deve imitar o comportamento do usuário e o teste ficará mais robusto, uma vez que a interação do usuário pouco mudará, em reação a ids, classes e outros detalhes de implementação.

Quanto mais o teste se assemelhar à forma como o software é utilizado, mais confiante será.

Localizar um elemento pelo texto, conforme um usuário faria:

await page.locator('text=Login');

em vez de localizar um elemento pelo ID:

await page.locator('#login-button');

Utilizar localizadores em vez de seletores

O uso de localizadores previne imprevisibilidades ou quebras imprevistas quando a página muda. Essas quebras podem não ser percebidas e o teste falhar, se foram utilizados seletores.

Usar:

await page.locator('text=Login').click();

em vez de:

await page.click('text=Login');

Os localizadores ajudarão a mitigar imprevisibilidades, devido a seu nível de restrição.

Se muitos elementos iguais surgirem na página, o uso de localizadores fará com que o teste "reclame" disso. O teste falhará e exibirá uma mensagem melhor sobre a falha, em vez de simplesmente falhar.

Utilizar Page Object Model (POM)

Page Object Model (POM) é um design pattern que ajuda a evitar duplicação de código, melhora a manutenibilidade e simplifica interações entre páginas e múltiplos testes.

Não que seja necessário utilizar para tudo. Utilizar quando fizer sentido abstrair um trecho de código, se o teste se beneficiará dele.

Duplicação é mais barato do que uma abstração errada.
— Sandi Metz

Mais detalhes sobre o Page Object Model no próximo artigo.

Utilizar aspas duplas para encontrar elementos específicos

Se está encontrando múltiplos elementos com a mesma string, tente utilizar aspas duplas para habilitar "case sensivity".

Por exemplo: await page.locator('text=Checkout') pode retornar um botão com o texto "Checkout" e um título com o texto "Check out this new shoe".

Utilize aspas duplas para retornar somente o botão com o código:

await page.locator('text="Checkout"')

Ref: Playwright: text locator

Evite seletores amarrados à implementação

XPATH e CSS podem ser amarrados à estrutura ou implementação e podem facilmente serem alterados, então melhor evitar coisas como:

await locator (`#tsf > div:nth-child(2) >
div.A8SBwf > div.RNNXgb > div > div.a4bIc > input`).click();

Série de artigos sobre E2E:

Testes de UI resilientes a mudanças

Tarcisio C. Uchoa — Mon, 10 Feb 2025 18:05:12 +0000

Ref: Kent C. Dodds: Making your UI tests resilient to change
Ref: Autify Blog: Why you shouldn’t use ids in E2E testing
Ref: Cypress: Selecting Elements

Evitar buscar elementos pela tag genérica ou por classes, que estão sujeitas a alterações.

O ideal é fazer o teste o mais próximo possível de como o usuário faria.

O usuário não vai abrir o Dev Tools e procurar o elemento com o ID ou nome username-field, ele vai procurar o campo de usuário.

O cenário de teste mais próximo do que o usuário faria é:

Digitar o nome de usuário no campo com a label "Nome de usuário"
Digitar a senha no campo com a label "Senha"
Clicar no botão que tem o texto "Entrar"

Mas nem sempre é possível seguir os passos do usuário dessa forma, sem falar que se basear no texto também está sujeito a alterações (o campo "nome de usuário" pode mudar para "Usuário").

Buscar pelo ID ou class é interessante, mas se um sistema que utiliza Bootstrap (.btn-primary) passa a utilizar Styled Components, ou Material UI, ou Tailwind... é preciso refazer todos os testes para adaptar às novas classes.

Se reutilizarmos nomes de classes por conta de estilo, ou alterarmos nomes de casses ou até mesmo a estrutura de componentes (uma <div> ou <span> a mais ou a menos), a cada alteração, o teste precisa ser reescrito, indicando um teste fraco e falho.

O problema principal é que a relação entre o código e o teste está muito implícita. É necessário superar essa dificuldade tornando a relação mais explícita.

Então a forma ideal é criar um data-attribute como data-test para identificar os elementos que devem ser testados, garantindo que o data-attribute não será utilizado para nenhum outro propósito.

Adicionando "metadata" aos elementos que serão explicitamente testados. Tornando a relação entre o código e o teste mais explícita e o desenvolvedor pode alterar ids, classes e estruturas sem dificuldade, desde que mantendo a indicação do teste explícita com o data-attribute .

<button
    type="submit"
    name="submit"
    id="form1234-submt"
    class="btn btn-primary"
    data-test="login-btn-submit"> ✅
    Enviar
</button>

Mais código para escrever?

Embora seja a prática ideal, os desenvolvedores têm que se preocupar agora, além dos Ids , também com os data-test para manter a compatibilidade entre o código e o teste, evitando repeti-los ou removê-los ou alterá-los em refatorações de código ou criação de novos.

Uma possibilidade para diminuir riscos e ainda manter a referência é identificar componentes maiores com o data-attribute , em vez de identificar todos os componentes individualmente.

Talvez escrever:

<div class="modal" tabindex="-1" role="dialog" 👉🏻data-test="modal"👈🏻>
  <div class="modal-dialog" role="document">
    <div class="modal-content">
      <div class="modal-header">        
        <h5 class="modal-title">Confirm</h5>
          <button
            type="button"
            class="close"
            data-dismiss="modal"
            aria-label="Close">
          <span aria-hidden="true">&times;</span>        
        </button>      
      </div>      
      <div class="modal-body">
        <p>Really submit?</p>     
      </div>
      <div class="modal-footer">        
        <button
          type="button"
          class="btn btn-primary">
          Submit
        </button>
        <button
          type="button"
          class="btn btn-secondary"
          data-dismiss="modal">
            Cancel
        </button>
      </div>   
    </div> 
  </div>
</div>

Em vez de :

<div class="modal" tabindex="-1" role="dialog" 👉🏻data-test="modal"👈🏻>
    <div class="modal-dialog" role="document">
        <div class="modal-content">
            <div class="modal-header">        
                <h5 class="modal-title" 👉🏻data-test="modal-title"👈🏻>Confirm</h5>
                <button
                    type="button"
                    class="close"
                    data-dismiss="modal"
                    aria-label="Close"
                   👉🏻data-test="modal-close"👈🏻>
                    <span aria-hidden="true">&times;</span>        
                </button>      
            </div>      
            <div class="modal-body" 👉🏻data-test="modal-body"👈🏻>
                <p>Really submit?</p>     
            </div>
            <div class="modal-footer">        
                 <button
                     type="button"
                     class="btn btn-primary"
                    👉🏻data-test="modal-btn-submit"👈🏻>
                     Submit</button>        
                 <button
                     type="button"
                     class="btn btn-secondary"
                     data-dismiss="modal"
                    👉🏻data-test="modal-btn-cancel"👈🏻>Cancel</button>
            </div>   
        </div> 
    </div>
</div>

Assim é possível se basear no componente maior para localizar os itens internos:

this.page.locator('data-test=modal >> button:has-text("Submit")')

O código acima busca somente o botão com o texto "Submit" que está dentro do elemento com o data-test=modal , ignorando outros botões, possivelmente com o mesmo texto.

Dependendo do formato e tamanho do projeto, isso pode ser útil.

Suja o código?

Se houver alguma preocupação com o fato de colocar em produção data-attributes que indiquem os testes (não é um grande problema, mas...), é possível remover esses atributos de produção com plugins como o babel-plugin-react-remove-properties.

Boas práticas do Cypress

Utilização de atributos data-* provém melhor contexto aos seletores, isolando das alterações de CSS e JavaScript.

Evitar localizar elementos por tags , classes e Ids , altamente sujeitos a mudanças.
É interessante localizar objetos pelo texto, se o conteúdo do texto fizer parte do cenário de teste, evitar se for um objeto que o texto pode ser alterado e não faça sentido para o teste.
Utilizar data-attributes facilita a identificação dos elementos exclusiva para testes, isolando de alterações de HTML, JS e CSS.

Quando utilizar a localização por texto?

await page.locator('text=Log in').click();

Se o conteúdo (texto) do elemento alterar, você quer que o teste falhe?

Se SIM: localizar o elemento por texto
Se NÃO: localizar o elemento por data-attribute

Possível conclusão

O que deve ser imutável em uma aplicação não são suas casses ou Ids, mas o comportamento.
Quando o comportamento é alterado, o teste E2E deve detectar isso.
Testes E2E não devem travar o desenvolvimento além do comportamento.

Considerando isso, semelhante ao indicado nas boas práticas do Cypress, é interessante utilizar a localização por texto (quando necessário) e um pouco mais de data-attribute.

Localizar elementos por texto, quando necessário
Usar data-attributes, preferencialmente para identificar componentes UI e não todos os elementos individualmente.

Vantagens:

Não emprega Ids e classes internas, garantindo a manutenibilidade do código.
Comparado ao uso massivo de data-attributes, diminui o custo de desenvolvimento e manutenção de código.

Série de artigos sobre E2E:

Melhores práticas para criação e automação de testes E2E

Tarcisio C. Uchoa — Mon, 10 Feb 2025 17:55:36 +0000

Ref: Best practices for creating end-to-end tests

Os testes E2E são críticos para monitorar fluxos de trabalho chaves de uma aplicação — como criar uma conta ou adicionar itens num carrinho de compras — e garantir que os usuários não encontrem funcionalidades quebradas.

É importante criar um plano de testes que provêm uma cobertura apropriada e fácil de adotar e manter a longo prazo.

As melhores práticas para criação de testes E2E incluem:

Definir a cobertura de testes
Criar testes eficientes e significativos
Desenhar suítes de teste coerentes e fáceis de navegar
Criar notificações que permitam que o time responda aos problemas rapidamente

Definir a cobertura de testes

Antes de começar a criar os testes, é importante considerar os fluxos da aplicação que devem ser testados. Nem todos os fluxos da aplicação cabem nos testes E2E.

Não deixar os testes muito grandes, complexos e de difícil manutenção.

A cobertura de testes deve ser representativa para os usuários e como eles usam a aplicação.

Identificar e priorizar os fluxos de trabalho mais utilizados da aplicação. Assim, colocando no escopo das suítes de teste o que traz mais valor para o negócio.

Essa abordagem ajudará a alcançar melhor balanço entre cobertura de testes e manutenibilidade.

Fluxos-chave de uma aplicação podem incluir:

Criar ou entrar numa conta.
Agendar um voo.
Adicionar itens num carrinho de compras.
Ver a lista de empregados de uma companhia.
Fazer um depósito na conta.

Interessante descobrir quais os principais fluxos utilizados na aplicação. Ferramentas como RUM (Real User Monitoring) da Datadog, ou mesmo acompanhar o Google Analytics. Ver quais as URLs mais visitadas, quais os fluxos mais utilizados.

Além de testar os fluxos mais populares, é importante criar testes para os fluxos não tão utilizados, mas ainda assim críticos (como recuperar a senha ou editar o perfil). Criar testes para esses fluxos permite identificar problemas de funcionalidade antes que os clientes reclamem.

Criar testes eficientes e significativos para fluxos chave

Sem um bom plano de testes de como abordar um fluxo de trabalho específico, os testes podem se tornar complexos, com um número grande de passos, dependências e asserções desnecessárias, aumentando as falhas e tempo de execução, tornando mais difícil de resolver e responder aos problemas rapidamente.

Boas práticas para suítes de testes mais eficientes:

Quebrar fluxos de trabalho em testes menores
Criar asserções significativas para verificar o comportamento esperado
Criar testes que se adaptem a fatores fora do nosso controle
Manter o estado da aplicação para que testes possam ser executados mais de uma vez sem alterar o resultado

Quebrar fluxos de trabalho em testes menores

É importante criar testes que não dupliquem passos.

Separar fluxos de teste em testes menores e mais focados ajuda a manter o escopo, reduz pontos de manutenção e facilita encontrar erros e falhas.

Por exemplo: um teste que verifica a funcionalidade de carrinho de compras, não precisa incluir os passos de criar uma conta. Se o teste falhar, você não vai querer perder tempo tentando descobrir onde ocorreu a falha: no carrinho ou na hora de criar a conta.

Separar testes menores que podem ser reutilizados.

Utilizar a prática DRY (don’t repeat yourself) e Page Object Models (POM), onde organizamos os itens e ações de uma página ou componente em um arquivo separado, que serão chamados nos testes definitivos.

Criar componentes de teste, da mesma forma que separamos componentes em front-end. Em caso de falhas, basta localizar e reparar apenas aquele componente e não uma suíte inteira de testes.

Criar asserções significativas para verificar o comportamento esperado

Construir suítes de testes eficientes é garantir que os testes verifiquem comportamentos importantes da aplicação.

As asserções do teste são passos que descrevem o fluxo lógico de uma ação na aplicação. Elas adicionam valor aos testes imitando o que os usuários esperam ver quando eles interagem com a aplicação.

Exemplo: uma asserção pode confirmar que o usuário é redirecionado para a página inicial e vê uma mensagem de boas-vindas após fazer o login.

Asserções comumente usadas em testes:

Um elemento tem (ou não tem) determinado conteúdo.
Um elemento ou texto está presente (ou não) em uma página.
Uma URL contém um determinado texto, número ou expressão regular.
Um arquivo foi baixado.
Um e-mail foi enviado e inclui determinado texto.

É importante incluir apenas asserções que imitam o que o usuário espera que aconteça num fluxo de trabalho.

Um teste da funcionalidade de compra, por exemplo, apenas precisa incluir asserções que são relevantes à compra, como verificar a confirmação.

Criar testes que se adaptem a fatores fora do nosso controle

Teste geralmente falham se a aplicação demorar para carregar. O tempo de carregamento pode ser afetado por fatores como uma inesperada falha na rede ou uma onda incomum de tráfego que pode sobrecarregar o servidor.

Inconsistências de demora no carregamento podem levar a falsos positivos, e adicionar tempos de espera manualmente no teste (hard coding) pode deixar os testes menos confiáveis.

Uma melhor prática de garantir que os testes se adaptem a flutuações de tempo é desenhá-los para esperar automaticamente até que uma página esteja pronta para interagir antes de executar (ou refazer) um passo de teste.

Isso não apenas elimina a necessidade de adicionar esperas no código, como também permite focar em falhas legítimas no ambiente de produção.

//exemplo no Playwright: aguardando o estado "network idle" antes de testar

async navigate(): Promise<void> {
    const url = await this.page.url();
    if (url != this.baseUrl) {
        await this.page.goto(this.baseUrl);
    }
    await this.page.waitForLoadState('networkidle');
}

await frame.click('button');  // o clique aciona a execução
await frame.waitForLoadState();  // espera pelo estado de "carregado"

Ref: Playwright: waitForLoadState

O Playwright realiza uma série de verificações de ação nos elementos antes de executar ações para garantir que essas ações se comportem conforme o esperado. Ele espera automaticamente que todas as verificações relevantes sejam aprovadas e só então executa a ação solicitada. Se as verificações necessárias não passarem dentro do timeout fornecido, a ação falhará com o TimeoutError.

Por exemplo, para page.click(), o Playwright garantirá que:

o elemento está presente no DOM
o elemento está visível
o elemento está estável, não está sendo animado ou terminou a animação
o elemento pode receber um evento/ação, não está ofuscado por outros elementos
o elemento está habilitado

Ref: Playwright: Auto-waiting

Manter o estado da aplicação para que testes possam ser executados mais de uma vez sem alterar o resultado

Testes dependem de dados limpos para recriar os passos para cada execução. É importante ter configurações dedicadas aos testes (credenciais de login, ambientes, cookies) que são usadas somente nos testes.

É importante criar testes que possam ser executados sem serem afetados pelos seus próprios resultados, os testes devem deixar o estado da aplicação e ambiente de teste sem alteração antes e depois da execução.

Um teste que foca em adicionar múltiplos itens em um carrinho de compras, por exemplo, deve possuir um mecanismo que exclua os itens do carrinho depois.

É interessante ter um recurso que consiga apagar do banco de dados as transações executadas pelos testes.

Também é possível ter subtestes que limpem a execução dos testes após cada execução (afterAll).

test.beforeAll(async ({ browser }) => {
    page = await browser.newPage();
    homePage = new HomePage(page, BASE_URL);
    await homePage.navigate();
});

test('do tests', async () => {
    // faz os testes
});

test.afterAll(async () => {
    await homePage.clean(); // volta ao estado original
    await page.close();
});

Desenhar suítes de teste coerentes e fáceis de navegar

Configurar testes por ambiente

Cada ambiente que é utilizado para testar as funcionalidades durante o desenvolvimento podem requerer configurações diferentes para rodar os testes.

Por exemplo: testes em ambiente de desenvolvimento talvez só precisem executar em um dispositivo, enquanto testes em pré-produção requerem vários diferentes tipos de dispositivos.

O ideal é separar os testes por ambiente para garantir que serão executados somente o necessário para cada ambiente.

Outra dica é identificar nos títulos dos testes o ambiente/dispositivo testado, facilitando a identificação e/ou correção quando um teste falhar.

Importante configurar variáveis de ambiente quando colocar os testes em integração contínua (CI).

Organizar testes por localidade, dispositivos e mais

Encontrar maneiras de organizar e categorizar os testes é um outro aspecto chave para desenvolver suítes de testes coerentes.

Desenhando uma boa estrutura organizacional permite gerenciar facilmente as suítes de teste enquanto eles aumentam.

Uma forma de adicionar estrutura aos testes é incorporar metadados ou etiquetas como tipo de teste, ambiente e dispositivo. Etiquetas (tags) provém melhor contexto sobre o que está sendo testado, facilitando encontrar quais fluxos de trabalho estão quebrando.

Apenas adicionando o ambiente no título do teste ajuda identificar onde o teste está executando. Tags também permite categorizar os testes com atributos chave no momento de criar os testes.

Adicionar metadados e tags aos testes é especialmente útil se você gerenciar uma suíte muito grande de testes e precisa revisar apenas uma parte deles. Por exemplo, pode usar uma tag “team” para buscar e executar testes de um time que desenvolveu uma funcionalidade ou a tag “site” para encontrar os testes associados a um site específico.

Interessante utilizar tags nos testes (o Playwright permite) para identificar e executar facilmente apenas os testes prioritários (smoke tests), ou talvez testes relacionados a uma sprint ou funcionalidade.

Escrevendo tags no Playwright:

import { test, expect } from '@playwright/test';

test('Test login page @fast', async ({ page }) => {
    // ...
});

test('Test full report @slow', async ({ page }) => {
    // ...
});

Você poderá então rodar apenas os testes com uma determinada a tag:

npx playwright test --grep @fast

Ou se quiser o contrário, pular os testes com uma determinada tag:

npx playwright test --grep-invert @slow

Ref: Playwright: Tag tests

Criar notificações que permitam que o time responda aos problemas rapidamente

Independentemente de como você estrutura os testes ou onde os executa, é importante que o time esteja apto para acessar rapidamente as falhas dos testes, assim como saberem quando a suíte de testes finalizou a execução com sucesso.

Se você está executando testes de um serviço crítico em produção, os desenvolvedores deverão saber o estado e resultado dos testes assim que possível. Se todos os testes passaram, eles poderão seguir adiante com o desenvolvimento. Se há falhas, eles precisam ser notificados imediatamente para resolver os problemas rapidamente.

Relatórios de teste geralmente são difíceis de analisar, especialmente se você adiciona mais testes à suíte. Se executar os testes em diferentes dispositivos, você precisará ver vários diferentes relatórios para encontrar falhas em cada dispositivo. Perdendo mais tempos navegando no resultado dos testes do que em encontrar e consertar o problema.

O ideal seria construir notificações que automaticamente consolidem e encaminhem os resultados para os times apropriados, provendo o contexto necessário sobre o que foi testado.

Interessante configurar que o teste (CI) notifique por e-mail ou envie para grupos no Teams, por exemplo.

Série de artigos sobre E2E:

Teste E2E (end-to-end)

Tarcisio C. Uchoa — Mon, 10 Feb 2025 17:41:04 +0000

O teste end-to-end é uma metodologia utilizada para testar se o fluxo de um aplicativo está sendo executado conforme o projeto do início ao fim. O objetivo da realização de testes end-to-end é identificar dependências do sistema e garantir que a informação certa seja passada entre vários componentes e sistemas.

Resumindo, o teste end-to-end é um forma de realizar testes nas quais visam provar o sistema de uma forma mais completa simulando o ambiente real.

É importante criar um plano de testes que provêm uma cobertura apropriada e fácil de adotar e manter a longo prazo. Veja nosso documento de Melhores práticas para criar testes E2E.

Automação de teste E2E com Playwright

https://playwright.dev/

Vantagens dos Testes Automatizados no Front-End

Testes de ponta a ponta, simulando todas as possíveis interações do usuário, sem dependência de interações manuais.
Garantir qualidade após mudanças.
Diminuição do tempo de testes antes de lançar uma nova versão.
A cada nova funcionalidade lançada e testada manualmente, os testes automatizados garantem que nada que já funciona foi alterado.
Revalidar todo o sistema a cada atualização do código.
Ajuda a manter uma documentação viva.

Vantagens do Playwright

Executa nos principais navegadores: Chrome, Firefox, Webkit (Safari) e Edge.
Simula dispositivos (Android, iOS) e resoluções.
Auto-wait: com ele é possível tornar a escrita de testes mais simples, permitindo que o desenvolvedor se preocupe somente com as interações com o navegador, deixando o trabalho de aguardar os elementos totalmente com o framework.
Recorder/CodeGen: o Playwright permite que o desenvolvedor execute as ações de um teste manualmente e essas ações são gravadas em forma de código, facilitando a criação dos testes. A ferramenta também possui um buscador de seletores (semelhante ao “inspecionar elemento” do DevTools) que permite validar os seletores escritos pelo desenvolvedor ou buscar novos seletores para escrever o teste.
Possui mais ferramentas e tem melhor desempenho que outros frameworks de teste E2E.