Perché non Ajax?
Questo mi sembra un ottimo posto per il test unitario. Come punto di entrata / uscita dentro e fuori da un determinato dominio, quello è un punto di strozzatura in cui è bello sapere che il tuo codice gestirà i cattivi dati nel miglior modo possibile. Idealmente, un problema di rete o di dati non genererà i tipi di eccezioni che infrangeranno il codice sulla tua pagina e forniranno il feedback degli utenti come appropriato. Ma vorrei sottolineare la convalida della registrazione live qui come prima strategia.
Semi-concordato nell'interfaccia DOM
Tutto ciò che puoi verificare è se qualcosa funziona quando tutto il codice HTML è corretto. Non puoi davvero fare supposizioni su cosa dovrebbe fare il tuo codice quando l'HTML è rotto perché convalidare per ogni piccola operazione DOM è troppo costoso. Inoltre, la rottura è in genere così ovvia che è comunque uno sforzo inutile. È meglio semplicemente avere pagine di test piene di variazioni in produzione su widget completamente funzionali con l'attivazione automatica delle loro varie funzionalità. Se ciò vale come test unitario, suppongo di non essere d'accordo.
Accordo sull'unità Testing dei dati: giocoleria / formattazione dei dati / logica
Questo è sicuramente il livello interno in cui potrebbe essere più sensato concentrarsi su una sorta di strategia di test.
Ma ancora non venduto al 100% su numerosi test della Web Unit lato client
Ne sono fuori discussione soprattutto perché è oscenamente facile testare il codice prima di commetterlo e i problemi sono in genere molto visibili sul lato client. Se non ottieni indicazioni visive immediate, vedrai problemi nella console.
IMO, la cosa fondamentale è concentrarsi sulla verifica di come il tuo codice reagisce a cose cattive da vettori che non controlli come quello che arriva da Ajax o JSON abbandonato dal server al caricamento della pagina. Problemi di regressione della varietà di bug whack-a-mole in cui una "correzione" interrompe qualcosa altrove è qualcosa che qualsiasi sviluppatore web lato client dovrebbe essere restio a non consentire mai nel proprio codice in primo luogo mantenendo separazioni pulite di preoccupazioni e test manuali la schifezza di tutto il loro lavoro in ogni browser supportato prima di impegnarsi. Ciò richiede tempo e direi che il tempo è meglio speso, evitando il problema in primo luogo rispetto al test per vedere se non si è riusciti a evitarlo. La flessibilità di JS semplifica la riduzione della complessità che tenderei a sostenere per i test automatici solo a colli di bottiglia chiave e la gestione dei dati necessariamente complessa.
In un recente lavoro con un codebase molto disordinato che non è stato più toccato dalle mani degli sviluppatori client-side, l'IMO di time-saver di debug più critico, sta prima stabilendo un modo per escludere molto rapidamente se è effettivamente un client-side problema. Se si stanno convalidando tutti i dati da e verso il server e si registrano problemi (silenziosamente in produzione ovviamente) nel momento in cui si verificano, questo può essere questione di secondi anziché di ore. Ma non si tratta di test unitari, bensì di validazione, che direi più importante dei test unitari quando puoi eseguire e diagnosticare il tuo codice in un ambiente live il più facilmente possibile con il codice web sul lato client.
Considera una strategia mista
Quindi non sto dicendo che sia sempre una cattiva idea. Penso che con JavaScript sia bravo in quello che è molto bravo e con lo sviluppo sul web del lato client che è l'unico animale che è, è meglio dedicare del tempo ad evitare il tipo di complessità inutile che fa preoccupare i problemi di regressione in primo luogo e concentrarsi maggiormente sulla diagnosi rapida dei problemi nel proprio ambiente di lavoro. Le pagine di test dei widget sono fantastiche. La convalida dell'ingresso / uscita dei dati e forse il test dell'unità di gestione degli errori è ottimo. E quando si ha a che fare con un'elevata complessità per la gestione / formattazione dei dati, i test unitari potrebbero anche essere grandiosi. Ma la copertura al 100% dei test unitari di un determinato livello, direi, è il tempo / lo sforzo che potrebbe essere meglio focalizzato altrove per una tipica applicazione web lato client.
