Testing de componentes con Testing Library

En JavaScript construiste tu propio runner y aprendiste a testear funciones puras (SC-02, M16). Testear COMPONENTES es el siguiente paso: probar que tu UI se comporta bien cuando el usuario interactúa. La clave —y la filosofía de Testing Library— es probar lo que el USUARIO ve y hace (texto en pantalla, clics, escritura), no los detalles internos del componente. Hoy dominas Vitest + React Testing Library: la red de seguridad de una app de producción.

Probar como usa un usuario, no como está hecho

Un test de componente

Con Vitest y Testing Library: render monta el componente, screen lo consulta como un usuario, userEvent simula interacciones, y expect verifica. Un ejemplo con un contador:

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

describe("Contador", () => {
it("empieza en 0 y suma al hacer clic", async () => {
  render(<Contador />);

  // consultar como un usuario: por el TEXTO/ROL que se ve, no por clases internas
  expect(screen.getByText("Cuenta: 0")).toBeInTheDocument();

  // interactuar como un usuario: clic en el botón por su nombre accesible
  const boton = screen.getByRole("button", { name: /sumar/i });
  await userEvent.click(boton);
  await userEvent.click(boton);

  // verificar el resultado VISIBLE
  expect(screen.getByText("Cuenta: 2")).toBeInTheDocument();
});
});

Fíjate cómo el test NUNCA toca el estado interno del Contador: busca el texto "Cuenta: 0" que el usuario ve, hace clic en el botón por su nombre accesible (getByRole("button", { name: /sumar/i })), y verifica que ahora se ve "Cuenta: 2". Si mañana reescribes el Contador con useReducer en vez de useState, el test SIGUE pasando —porque prueba el comportamiento, no la implementación—. Esa es la resiliencia que da Testing Library.

Las consultas y por qué importan

Cómo lo practicas y la pirámide

Mini-reto

Diseña los tests de un componente de formulario de gasto (en papel o en tu proyecto): 1) un test que verifique que, al enviar vacío, aparece el mensaje de error (busca el texto del error con getByText o getByRole("alert")); 2) un test que llene los campos con userEvent.type, envíe, y verifique que el gasto aparece en la lista; 3) di por qué consultas por rol/etiqueta y no por clases CSS. Nota cómo cada test describe un comportamiento que le importa al usuario.

Qué sigue

Ya sabes hacer tu app rápida, ligera y confiable. La última pieza de producción es cómo la ORGANIZAS para que crezca sin volverse un caos: la arquitectura por FEATURES. La próxima lección cierra el módulo con cómo estructurar carpetas y código en una app real que muchas personas mantienen.