Test-Fixture

Eine Test-Fixture ist alles, wovon ein Test abhängt, das nicht selbst das getestete Verhalten ist: die Objekte, Daten, Verbindungen und die Umgebung, die sich in einem bekannten Zustand befinden müssen, bevor der erste Schritt läuft. Eine gute Fixture stellt diesen Zustand jedes Mal auf dieselbe Weise her und baut ihn danach wieder ab, sodass jeder Test sauber startet. Das Wort wird auch lockerer für statische Testdatendateien verwendet, etwa die JSON-Dateien, die Cypress mit cy.fixture() lädt.

Beispiel (Playwright)

In Playwright sind Fixtures ein zentrales Feature. Eingebaute Fixtures wie page und request werden über ihren Namen injiziert, eigene fügen Sie mit test.extend hinzu:

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

Fixtures werden nur erzeugt, wenn ein Test sie anfordert, können von anderen Fixtures abhängen und lassen sich pro Test (Standard) oder für teure Ressourcen mit { scope: 'worker' } pro Worker scopen.

Beispiel (JUnit 5)

In Frameworks im xUnit-Stil steckt die Fixture in Lifecycle-Methoden:

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 und @AfterAll laufen einmal pro Klasse und müssen standardmäßig static sein.

Häufige Fehler

• Veränderlichen Fixture-Zustand zwischen Tests teilen. Ein Nutzer mit Worker-Scope, den Tests verändern, führt zu reihenfolgeabhängigen Fehlschlägen.
• Das Teardown überspringen, wenn ein Test fehlschlägt. Legen Sie das Aufräumen in die Fixture (nach use) oder in @AfterEach, nicht ans Ende des Testrumpfs.
• Eine riesige Fixture für alles. Kleine, kombinierbare Fixtures machen offensichtlich, wovon jeder Test abhängt.