Test fixture

Uma test fixture é tudo aquilo de que um teste depende e que não é o comportamento sob teste: os objetos, dados, conexões e o ambiente que precisam estar em um estado conhecido antes de o primeiro passo rodar. Uma boa fixture prepara esse estado sempre da mesma forma e o desmonta depois (teardown), para que cada teste comece limpo. A palavra também é usada de forma mais ampla para arquivos estáticos de massa de dados, como os arquivos JSON que o Cypress carrega com cy.fixture().

Exemplo (Playwright)

No Playwright, fixtures são um recurso de primeira classe. As nativas, como page e request, são injetadas pelo nome, e você adiciona as suas com 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);
});

As fixtures só são criadas quando um teste pede por elas, podem depender de outras fixtures e podem ter escopo por teste (padrão) ou por worker, com { scope: 'worker' }, para recursos caros.

Exemplo (JUnit 5)

Em frameworks no estilo xUnit, a fixture fica nos métodos de ciclo de vida:

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 rodam uma vez por classe e, por padrão, precisam ser static.

Erros comuns

• Compartilhar estado mutável da fixture entre testes. Um usuário com escopo de worker que os testes modificam vai causar falhas que dependem da ordem de execução.
• Pular o teardown quando um teste falha. Coloque a limpeza na fixture (depois do use) ou no @AfterEach, e não no fim do corpo do teste.
• Uma fixture gigante para tudo. Fixtures pequenas e combináveis deixam claro do que cada teste depende.