Design Patterns para Automação de Testes: Guia Prático com Playwright e Cypress

#testing #playwright #qa #automation

Design Patterns para Automação de Testes: Guia Prático

Se você já escreveu automação de testes, provavelmente já enfrentou aquele momento em que os testes ficam tão acoplados que qualquer mudança quebram dezenas de scripts. É aí que os Design Patterns entram.

Neste artigo, vamos ver os padrões mais usados na indústria, com exemplos práticos em Playwright e Cypress.

1. Page Object Model (POM)

O mais clássico e amplamente adotado. Separa a lógica de localização dos elementos da lógica dos testes.

// Playwright - Page Object
class LoginPage {
  constructor(private page: Page) {}

  private emailInput = () => this.page.locator('#email');
  private passwordInput = () => this.page.locator('#password');
  private submitButton = () => this.page.locator('button[type=submit]');

  async login(email: string, password: string) {
    await this.emailInput().fill(email);
    await this.passwordInput().fill(password);
    await this.submitButton().click();
  }
}

Vantagens: Manutenção centralizada, reutilizabilidade, código limpo nos testes.

2. Screenplay Pattern

Mais avançado, modela testes como atores realizando ações em um cenário. Excelente para testes complexos com múltiplos usuários.

3. Data-Driven Testing

Separa os dados dos testes da lógica. Ideal para validar múltiplas entradas no mesmo fluxo.

const testCases = [
  { user: 'admin', expected: 'Dashboard' },
  { user: 'viewer', expected: 'Read Only' },
];

for (const tc of testCases) {
  test(`Login as ${tc.user}`, async ({ page }) => {
    await loginAs(page, tc.user);
    await expect(page).toHaveTitle(tc.expected);
  });
}

4. Fixture Pattern (Cypress)

No Cypress, fixtures são nativos e permitem setup/teardown elegante:

test.use({
  storageState: 'auth.json',
});

 test('access dashboard', async ({ page }) => {
  await page.goto('/dashboard');
  await expect(page.locator('.stats')).toBeVisible();
});

Conclusão

Não existe um pattern perfeito para todos os casos. O ideal é combinar POM com Data-Driven e ajustar conforme a complexidade do projeto.

Quer aprender mais? Visite QA Overflow para tutoriais completos.

Artigo por Victor Oliveira - QA Senior com 13+ anos de experiência

DEV Community