React

Testing Library: i cinque test che servono

Cinque test coprono un componente React: rendering per ruolo, interazione, attesa asincrona, errore e validazione del form.

In sintesi

  • I test si scrivono sulle query per ruolo, non sulle classi o sull'ordine nel DOM.
  • userEvent simula il comportamento reale del browser, fireEvent no.
  • Cinque test coprono rendering, interazione, asincrono, errore e validazione: oltre si duplica.

Cinque test bastano per un componente React: che si veda, che risponda a un clic, che aspetti i dati, che mostri l'errore e che rifiuti un campo vuoto.

La regola di base

Testing Library, distribuita con licenza MIT, interroga il DOM come farebbe una persona: per ruolo, per etichetta, per testo visibile. Se un test non trova un pulsante per ruolo, spesso è il componente a essere poco accessibile, non il test.

Il test che vale come modello

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

test("invia l'email digitata", async () => {
  render();
  await userEvent.type(screen.getByLabelText("Email"), "[email protected]");
  await userEvent.click(screen.getByRole("button", { name: "Accedi" }));
  expect(onSubmit).toHaveBeenCalledWith({ email: "[email protected]" });
});

Il test digita con userEvent, che riproduce eventi reali, e verifica la chiamata invece dell'HTML: il markup interno può cambiare senza rompere il test.

I cinque test

  • Rendering: getByRole trova titolo e pulsante; se fallisce, manca un ruolo o un'etichetta.
  • Interazione: un clic cambia il testo visibile, verificato con findByText.
  • Asincrono: una risposta simulata arriva e il test la attende con await, senza setTimeout.
  • Errore: il componente lancia e l'error boundary mostra il messaggio previsto.
  • Validazione: il submit a form vuoto non chiama la callback e mostra il messaggio.

Installazione

npm i -D vitest jsdom @testing-library/react @testing-library/user-event
npx vitest run

Vitest e jsdom sono MIT, come Testing Library: nessun servizio esterno, i test girano in locale e in CI con lo stesso comando.

Tre componenti su cui scrivere subito i primi test: input, multistep-form e call-to-action-cta. Per esplorare per categoria parti da 111.985 componenti.

La limitazione

Questi test non dicono se il componente è veloce, né se il layout regge su mobile: jsdom non applica CSS, non calcola il layout e non misura i pixel. Un test verde su un form può convivere con un pulsante coperto da un altro elemento nella pagina vera.

Dove continuare

La checklist di accessibilità è in componenti React accessibili; come si legge la documentazione è in documentazione React; il quadro delle librerie è in che cos'è React; il confronto misurato fra le librerie React è in librerie React 2026.

Domande frequenti

Quanti test servono per un componente?

Cinque, di solito: rendering, interazione, asincrono, errore e validazione. Oltre si testano dettagli che il refactor cambia.

Meglio fireEvent o userEvent?

userEvent. Riproduce la sequenza reale di eventi del browser, mentre fireEvent ne lancia uno solo e salta focus e tastiera.

Posso testare le classi CSS?

No, e non conviene. Le classi cambiano con il refactor; verifica il testo visibile, i ruoli e gli attributi ARIA.

Serve un browser vero per i test?

Per logica e interazione no, basta jsdom. Per layout, CSS e screenshot serve un browser, con Playwright o simile.

Testing Library è gratis per uso commerciale?

Sì. È distribuita con licenza MIT, che permette uso commerciale e modifica mantenendo l'avviso di copyright.