Test fixture

Un test fixture es todo aquello de lo que depende un test y que no es el comportamiento bajo prueba: los objetos, datos, conexiones y el entorno que deben estar en un estado conocido antes de que se ejecute el primer paso. Un buen fixture prepara ese estado siempre de la misma manera y lo desmonta después, para que cada test empiece limpio. La palabra también se usa de forma más laxa para los archivos de datos de prueba estáticos, como los archivos JSON que Cypress carga con cy.fixture().

Ejemplo (Playwright)

En Playwright los fixtures son una funcionalidad de primera clase. Los integrados, como page y request, se inyectan por nombre, y puedes añadir los tuyos 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);
});

Los fixtures solo se crean cuando un test los pide, pueden depender de otros fixtures y pueden tener alcance por test (por defecto) o por worker con { scope: 'worker' } para los recursos costosos.

Ejemplo (JUnit 5)

En los frameworks de estilo xUnit, el fixture vive en los métodos del 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 y @AfterAll se ejecutan una vez por clase y, por defecto, deben ser static.

Errores comunes

• Compartir estado mutable del fixture entre tests. Un usuario con alcance de worker que los tests modifican provocará fallos que dependen del orden.
• Saltarse la limpieza cuando un test falla. Pon la limpieza en el fixture (después de use) o en @AfterEach, no al final del cuerpo del test.
• Un fixture gigante para todo. Los fixtures pequeños y combinables dejan claro de qué depende cada test.