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.