Test fixture

Una test fixture è tutto ciò da cui un test dipende e che non è il comportamento sotto test: gli oggetti, i dati, le connessioni e l’ambiente che devono trovarsi in uno stato noto prima che venga eseguito il primo passo. Una buona fixture prepara quello stato sempre allo stesso modo e lo smonta alla fine (teardown), così ogni test parte da zero. Il termine si usa anche in senso più ampio per i file di dati di test statici, come i file JSON che Cypress carica con cy.fixture().

Esempio (Playwright)

In Playwright le fixture sono una funzionalità di primo piano. Quelle integrate, come page e request, vengono iniettate per nome, e puoi aggiungere le tue con 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);
});

Le fixture vengono create solo quando un test le richiede, possono dipendere da altre fixture e possono avere scope per singolo test (predefinito) o per worker con { scope: 'worker' }, utile per le risorse costose.

Esempio (JUnit 5)

Nei framework in stile xUnit la fixture vive nei metodi del ciclo di vita:

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 e @AfterAll vengono eseguiti una volta per classe e per impostazione predefinita devono essere static.

Errori comuni

• Condividere tra i test uno stato mutabile della fixture. Un utente con scope di worker che i test modificano causerà fallimenti che dipendono dall’ordine di esecuzione.
• Saltare il teardown quando un test fallisce. Metti la pulizia nella fixture (dopo use) o in @AfterEach, non alla fine del corpo del test.
• Un’unica fixture gigante per tutto. Fixture piccole e componibili rendono evidente da cosa dipende ciascun test.