Glossario · Automazione della UI
Data-driven testing (test guidati dai dati)
In inglese: Data-driven testing
Detto anche: test guidati dai dati, test parametrizzati, parameterized tests, data-driven test
Definizione
Eseguire la stessa logica di test su molti insiemi di input e risultati attesi, tenuti in una tabella, un file o una sorgente dati invece che copiati in ogni test.
Il data-driven testing (test guidati dai dati) separa ciò che un test fa dai dati con cui lo fa. Scrivi i passi una volta sola, poi fornisci righe di dati: gli input e il risultato che ciascuno deve produrre. Ogni riga viene eseguita come un caso di test a sé, con il proprio esito positivo o negativo. È il modo naturale per automatizzare il risultato di tecniche come l’analisi dei valori limite e il partizionamento in classi di equivalenza.
Esempio (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);
}
}
Serve l’artifact junit-jupiter-params. Altre sorgenti sono @ValueSource, @MethodSource e @CsvFileSource per i dati tenuti in un file CSV.
Esempio (Playwright)
Playwright non ha un’annotazione apposita: generi i test in un ciclo, dando a ciascuno un titolo univoco:
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);
});
}
Errori comuni
- Righe che richiedono passi diversi. Se metà delle righe ha bisogno di un clic in più, hai due test, non uno con dei condizionali.
- Nomi illeggibili. Includi gli input principali nel nome di ogni caso, così che il report di un fallimento ti dica quale riga si è rotta.
- Enormi fogli di calcolo esterni. I dati lontani dal test sono difficili da revisionare. Tieni le tabelle piccole inline; passa ai file solo quando i dati sono davvero tanti o sono gestiti da qualcun altro.
- Quantità invece di valore. Cinquanta righe della stessa classe di equivalenza aggiungono tempo di esecuzione, non copertura.