Il testing è come l'assicurazione: nessuno lo ama, ma quando serve ti salva. Il problema è che troppo testing rallenta lo sviluppo. Troppo poco, e i bug raggiungono gli utenti. Serve equilibrio.
La piramide rovesciata
La teoria dice: molti unit test, meno integration, pochi e2e. La pratica dice: nel frontend, gli integration test danno più valore. Un test che renderizza un componente e verifica il comportamento cattura più bug di dieci unit test su funzioni helper.
Testing Library: test come utenti
React Testing Library vi forza a testare ciò che l'utente vede. Niente query su classi CSS o struttura DOM interna. Cercate per testo, role, label. Se dovete cambiare il test quando refactorate, state testando l'implementazione, non il comportamento.
Quando gli e2e valgono la pena
Flussi critici: login, checkout, iscrizione. Se si rompono, il business si ferma. Un test Cypress che percorre l'happy path vi fa dormire tranquilli. Ma non esagerate: sono lenti e fragili.
Coverage: la metrica fuorviante
80% di coverage non significa che il vostro codice funziona. Significa che l'80% delle righe viene eseguito. Potete avere 100% coverage e zero assertion. Focus sulla qualità dei test, non sulla percentuale.