Descrizione:
Cosa succeede se i test che scriviamo nel nostro team/azienda non sono facilmente leggibili (o addirittura "decifrabili")? Succede che i test stessi, invece che garantire confidenza sul fatto che il codice e l'app funzionino, aggiungono carico cognitivo invece che toglierlo, non permettono di capire cosa il codice e l'app dovrebbero fare perch sono pi complessi del codice stesso che dovrebbero testare, non danno confidenza nel fare refactoring, sono obsoleti rispetto al codice che devono testare Senza parlare che quando falliscono, non permettono di identificare il problema alla base del fallimento - non permettono di capire se il codice che non funziona o sono i test stessi che non funzionano, ci portano ad accettare i continui fallimenti Riasumendo, il costo di avere test (CI pi lente, sviluppo pi lento, librerie esterne da mantenere aggiornate) non ripagato dal vantaggio di averli. Senza dimenticarsi che tutti i punti di cui sopra frustrano non poco il team Durante il talk condivider con voi le best practice generiche che ho imparato nel tempo per evitare di incappare nei problemi sopracitati, applicabili ad ogni tipo di test (Unit test, Component test, Integration test, Story test, E2E test).
Questo è un argomento di discussione collegato all'originale su: https://www.meetup.com/react-js-milano/events/288495189/