Data-driven testing (tests pilotés par les données)

Le data-driven testing (tests pilotés par les données) sépare ce que fait un test des données avec lesquelles il le fait. Vous écrivez les étapes une seule fois, puis vous fournissez des lignes de données : les entrées et le résultat que chacune doit produire. Chaque ligne s’exécute comme un cas de test à part entière, avec son propre succès ou échec. C’est la façon naturelle d’automatiser le résultat de techniques comme l’analyse des valeurs limites et le partitionnement en classes d’équivalence.

Exemple (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);
    }
}

Cela nécessite l’artefact junit-jupiter-params. Parmi les autres sources figurent @ValueSource, @MethodSource et @CsvFileSource pour des données stockées dans un fichier CSV.

Exemple (Playwright)

Playwright n’a pas d’annotation dédiée ; vous générez les tests dans une boucle, en donnant à chacun un titre unique :

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);
  });
}

Erreurs courantes

• Des lignes qui nécessitent des étapes différentes. Si la moitié des lignes demande un clic supplémentaire, vous avez deux tests, pas un seul test truffé de conditions.
• Des noms illisibles. Incluez les entrées clés dans le nom de chaque cas, pour qu’un rapport d’échec vous indique quelle ligne a cassé.
• D’immenses tableurs externes. Des données éloignées du test sont difficiles à relire. Gardez les petits tableaux inline ; passez à des fichiers seulement quand les données sont réellement volumineuses ou gérées par quelqu’un d’autre.
• Le volume plutôt que la valeur. Cinquante lignes issues de la même classe d’équivalence ajoutent du temps d’exécution, pas de la couverture.