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:
getByRoletrova 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, senzasetTimeout. - 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.
Record vivi nel catalogo
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.