Fixture de test

Une fixture de test (test fixture) regroupe tout ce dont dépend un test sans être le comportement testé : les objets, les données, les connexions et l’environnement qui doivent être dans un état connu avant la première étape. Une bonne fixture met cet état en place de la même manière à chaque fois et le démonte ensuite, pour que chaque test démarre sur une base propre. Le mot s’emploie aussi plus largement pour des fichiers de données de test statiques, comme les fichiers JSON que Cypress charge avec cy.fixture().

Exemple (Playwright)

Dans Playwright, les fixtures sont une fonctionnalité de premier plan. Les fixtures intégrées comme page et request sont injectées par leur nom, et vous ajoutez les vôtres avec test.extend :

import { test as base, expect } from '@playwright/test';
import { TodoPage } from './todo-page';

type Fixtures = { todoPage: TodoPage };

export const test = base.extend<Fixtures>({
  todoPage: async ({ page }, use) => {
    const todoPage = new TodoPage(page);   // setup
    await todoPage.goto();
    await use(todoPage);                   // the test runs here
    await todoPage.removeAll();            // teardown
  },
});

test('adds an item', async ({ todoPage }) => {
  await todoPage.add('Write the glossary');
  await expect(todoPage.items).toHaveCount(1);
});

Les fixtures ne sont créées que lorsqu’un test les demande, peuvent dépendre d’autres fixtures et peuvent avoir une portée par test (par défaut) ou par worker avec { scope: 'worker' } pour les ressources coûteuses.

Exemple (JUnit 5)

Dans les frameworks de type xUnit, la fixture se trouve dans les méthodes de cycle de vie :

class CartServiceTest {
    private CartService cart;

    @BeforeEach
    void setUp() {
        cart = new CartService(new InMemoryCartRepository());
    }

    @AfterEach
    void tearDown() {
        cart.clear();
    }

    @Test
    void emptyCartHasZeroTotal() {
        assertEquals(0, cart.total());
    }
}

@BeforeAll et @AfterAll s’exécutent une seule fois par classe et doivent être static par défaut.

Erreurs fréquentes

• Partager un état de fixture modifiable entre les tests. Un utilisateur de portée worker que les tests modifient provoquera des échecs qui dépendent de l’ordre d’exécution.
• Sauter le nettoyage quand un test échoue. Placez le nettoyage dans la fixture (après use) ou dans @AfterEach, pas à la fin du corps du test.
• Une fixture géante pour tout. Des fixtures petites et composables rendent évident ce dont chaque test dépend.