Testing de componentes con React Testing Library

Probar como el usuario

React Testing Library (RTL) es la herramienta de referencia para probar componentes. Su filosofía es explícita:

Cuanto más se parezcan tus pruebas a la forma en que se usa tu software, más confianza te darán.

Por eso RTL te empuja a interactuar con el componente como lo haría una persona (buscando textos, etiquetas y roles) y no a inspeccionar detalles internos como el estado o los nombres de los métodos.

Esta lección es conceptual: el runtime de los ejercicios no incluye RTL. Aquí aprendes la filosofía y la API; el repaso se hace con cuestionarios.

El flujo básico: render, screen, eventos

import { render, screen } from "@testing-library/react";
import userEvent from "@testing-library/user-event";
import Contador from "./Contador";

test("incrementa al pulsar el botón", async () => {
  render(<Contador />);

  // Buscar como el usuario: por lo que se ve.
  expect(screen.getByText("Cuenta: 0")).toBeInTheDocument();

  // Interactuar como el usuario: pulsar el botón.
  await userEvent.click(screen.getByRole("button", { name: "Sumar" }));

  expect(screen.getByText("Cuenta: 1")).toBeInTheDocument();
});

• render monta el componente en un DOM de prueba.
• screen ofrece las consultas. Se prefieren las que buscan por lo que el usuario percibe:
  • getByRole (lo recomendado): busca por el rol de accesibilidad (button, heading, textbox...), opcionalmente con su nombre accesible.
  • getByText, getByLabelText: por el texto visible o la etiqueta de un campo.
• fireEvent dispara eventos del DOM de bajo nivel. userEvent (de @testing-library/user-event) es una capa superior que simula interacciones más realistas (teclear carácter a carácter, foco, hover) y suele ser la opción preferida.

Comportamiento, no implementación

La idea de fondo: si renombras una variable de estado o cambias useState por useReducer, la prueba no debería romperse mientras la interfaz se comporte igual. Estás probando comportamiento observable, no detalles de implementación. Esto hace que las pruebas sobrevivan a los refactorizados.

¿Quién ejecuta las pruebas?

RTL solo ofrece las utilidades para renderizar y consultar; necesita un ejecutor de tests (test runner) que las corra. Los dos más habituales son Vitest (rápido, integrado con Vite) y Jest (el clásico). Ambos aportan test/it, expect y los matchers como toBe o toEqual.