React
Explica cómo probar componentes desde la perspectiva del usuario con queries accesibles, interacciones, asincronía y expectativas sobre comportamiento observable.
React Testing Library favorece interactuar como lo haría una persona: roles, nombres accesibles y contenido visible.
render(<LoginForm onSubmit={onSubmit} />);
await user.type(screen.getByLabelText(/correo/i), "nico@example.com");
await user.click(screen.getByRole("button", { name: /ingresar/i }));
expect(onSubmit).toHaveBeenCalledWith({ email: "nico@example.com" });Prefiere:
getByRole.getByLabelText.data-testid como último recurso.expect(await screen.findByText(/pedido cargado/i)).toBeInTheDocument();Usa findBy o waitFor cuando la interfaz cambia después.
Evita probar nombres de estado, métodos internos, cantidad exacta de renders o estructura privada.
Simula límites externos, no toda la aplicación. Mock Service Worker permite interceptar red manteniendo un flujo realista.
userEvent.act.Una prueba valiosa protege comportamiento, no implementación incidental.
muchas pruebas de funciones y componentes
menos pruebas de integración amplia
pocas E2E críticasNo se trata de una proporción fija. Coloca cada comportamiento en el nivel más pequeño que todavía represente confianza real.
it("submits a valid email", async () => {
const user = userEvent.setup();
const onSubmit = vi.fn();
render(<NewsletterForm onSubmit={onSubmit} />);
await user.type(
screen.getByRole("textbox", { name: /correo/i }),
"nico@example.com",
);
await user.click(screen.getByRole("button", { name: /suscribirme/i }));
expect(onSubmit).toHaveBeenCalledWith("nico@example.com");
});La prueba prepara, interactúa como usuario y verifica el resultado observable.
getByRole obliga a que el elemento tenga rol y nombre accesible correctos. Si falla, revisa primero la interfaz, no cambies inmediatamente a data-testid.
getBy*: debe existir ahora.queryBy*: puede no existir.findBy*: aparecerá asíncronamente.Usa within para limitar a una región:
const dialog = screen.getByRole("dialog", { name: /eliminar pedido/i });
expect(within(dialog).getByRole("button", { name: /confirmar/i })).toBeEnabled();userEvent reproduce secuencias más cercanas a interacción: focus, teclado, input y click. fireEvent sigue siendo útil para eventos específicos de bajo nivel, pero puede saltarse comportamiento real.
Siempre crea userEvent.setup() dentro de la prueba para manejar timers y async de forma predecible.
await user.click(loadButton);
expect(await screen.findByRole("heading", { name: /pedido 123/i })).toBeVisible();waitFor es apropiado cuando la expectativa se vuelve verdadera después:
await waitFor(() => expect(mock).toHaveBeenCalledTimes(1));No pongas acciones dentro de waitFor; puede repetirlas.
En vez de mockear el Hook de datos:
server.use(
http.get("/api/orders", () => HttpResponse.json(orders)),
);La UI ejecuta su flujo normal de fetch, caché y errores. Puedes variar:
Esto protege el contrato HTTP sin levantar backend real.
Crea una función de render que reciba opciones, no un wrapper global rígido:
function renderApp(ui: React.ReactNode, options?: RenderOptions) {
return render(
<TestRouter initialEntries={options?.routes}>
<SessionProvider value={options?.session ?? guestSession}>
{ui}
</SessionProvider>
</TestRouter>,
);
}Cada test declara el contexto relevante.
Para probar un componente controlado, crea un harness que actualice state:
function ControlledTabs() {
const [value, setValue] = useState("details");
return <Tabs value={value} onValueChange={setValue} />;
}Pasar un vi.fn() sin rerender puede probar el callback pero no el comportamiento completo.
Prueba:
No verifiques state interno; observa campos, mensajes y callbacks.
Un custom hook puede probarse mediante renderHook, pero si su valor solo tiene sentido en UI, un consumidor pequeño ofrece más confianza. Extrae cálculos puros y pruébalos sin React.
Usa fake timers cuando el comportamiento depende del tiempo, pero coordínalos con userEvent:
vi.useFakeTimers();
const user = userEvent.setup({ advanceTimers: vi.advanceTimersByTime });Avanza solo el tiempo necesario y restaura timers después. No uses esperas reales largas.
Testing Library consulta document.body, por lo que puede encontrar portales. Verifica:
Controla una Promise diferida para probar fallback y resolución. Para Error Boundary, un componente que lanza permite verificar fallback y retry. No acoples tests a promises internas de una librería.
Puedes envolver tests representativos en StrictMode para descubrir effects sin cleanup. No todos necesitan duplicación. Nunca hagas assertions frágiles sobre número exacto de renders o effects salvo que ese sea el contrato.
Útiles para estructuras pequeñas y estables, pero un snapshot enorme se acepta sin revisar. Prefiere assertions semánticas. Un cambio visual importante necesita visual regression o E2E, no solo HTML serializado.
100% de líneas no garantiza casos útiles. Prioriza:
Una línea trivial puede no necesitar test aislado; un caso de carrera sí.
Señales:
data-testid para controles con rol.Refactoriza hacia comportamiento y límites reales.
Reserva para flujos que cruzan sistema:
Mantén pocos, deterministas y con datos controlados.
findBy/waitFor, no sleeps.queryBy?useOrders?waitFor?Accesibilidad en componentes React profundiza en los contratos que estas queries ayudan a proteger.