Pular para o conteúdo
SDETRole
SDETRole

Glossário · Automação de UI

Teste orientado a dados

Em inglês: Data-driven testing

Também chamado de: testes orientados a dados, testes parametrizados, teste parametrizado, parameterized tests

Definição

Executar a mesma lógica de teste com vários conjuntos de entradas e saídas esperadas, mantidos em uma tabela, arquivo ou fonte de dados em vez de copiados em cada teste.

O teste orientado a dados (data-driven testing) separa o que o teste faz dos dados com os quais ele faz. Você escreve os passos uma vez e depois alimenta linhas de dados: as entradas e o resultado que cada uma deve produzir. Cada linha roda como um caso de teste próprio, com seu próprio resultado de aprovado ou reprovado. É a forma natural de automatizar o resultado de técnicas como análise de valor limite e particionamento de equivalência.

Exemplo (JUnit 5)

import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.CsvSource;
import static org.junit.jupiter.api.Assertions.assertEquals;

class ShippingFeeTest {

    @ParameterizedTest(name = "order of {0} costs {1} to ship")
    @CsvSource({
        "0.00,   4.99",
        "49.99,  4.99",
        "50.00,  0.00",
        "250.00, 0.00"
    })
    void shippingFee(double orderTotal, double expectedFee) {
        assertEquals(expectedFee, Shipping.feeFor(orderTotal), 0.001);
    }
}

Isso exige o artefato junit-jupiter-params. Outras fontes incluem @ValueSource, @MethodSource e @CsvFileSource para dados mantidos em um arquivo CSV.

Exemplo (Playwright)

O Playwright não tem uma anotação específica; você gera os testes em um loop, dando a cada um um título único:

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

const cases = [
  { email: '', error: 'Email is required' },
  { email: 'not-an-email', error: 'Enter a valid email' },
];

for (const { email, error } of cases) {
  test(`login rejects "${email}"`, async ({ page }) => {
    await page.goto('/login');
    await page.getByLabel('Email').fill(email);
    await page.getByRole('button', { name: 'Sign in' }).click();
    await expect(page.getByRole('alert')).toHaveText(error);
  });
}

Erros comuns

  • Linhas que precisam de passos diferentes. Se metade das linhas precisa de um clique a mais, você tem dois testes, e não um teste cheio de condicionais.
  • Nomes ilegíveis. Inclua as entradas principais no nome de cada caso, para que o relatório de falha diga qual linha quebrou.
  • Planilhas externas enormes. Dados longe do teste são difíceis de revisar. Mantenha tabelas pequenas inline; passe para arquivos só quando os dados forem realmente grandes ou pertencerem a outra pessoa.
  • Volume em vez de valor. Cinquenta linhas da mesma classe de equivalência aumentam o tempo de execução, não a cobertura.

Digite para buscar em todo o SDETRole.

Busca de texto completo com Pagefind · roda no seu navegador Abrir página de busca →