quanto tempo dedichi ai test unitari?

In un'azienda per cui lavoravo, i dirigenti hanno insistito sul fatto che la copertura del codice con i test unitari deve essere del 99% o più. Ciò ha comportato la scrittura di più test rispetto al codice. Ci sono voluti letteralmente 3 giorni per scrivere test per una singola classe che ha impiegato un giorno per essere implementata.

Di conseguenza, tuttavia, ho imparato molto su TDD, strumenti di test, pratiche ecc.

Nella società per cui ho lavorato in seguito, i test unitari erano una cosa sconosciuta. Era qualcosa che qualcuno avrebbe sentito prima. Ho faticato a introdurli al concetto di unit testing, ma senza effetto.

Ora, come lavoratore autonomo, mi chiedo: quanto tempo è davvero necessario da dedicare ai test unitari? Essendo principalmente sviluppatore iPhone / Android, quali parti del codice dovrebbero essere coperte nei test?

La quantità di test unitari necessari dipende da diversi fattori:

• Dimensioni del prodotto (maggiore è il progetto, maggiore è la necessità di includere almeno alcuni test unitari)
• Livello di qualità richiesto (se stai mettendo insieme software che deve essere eliminato il più rapidamente possibile e alcuni bug minori sono accettabili, potresti essere costretto a saltare alcuni test come i test unitari)
• Tipo di prodotto (l'interfaccia utente può essere testata dall'unità, ma a volte è più semplice saltare i test unitari su sezioni GUI pesanti di un progetto e invece testare manualmente)
• Abilità / storia del tuo codice (Che tipo di bug crei normalmente? Sono cose che i test di unità normalmente catturano o cose che un altro tipo di test normalmente trova. Sapere che questo potrebbe spingerti a fare più o meno test di unità)

Nel nostro gruppo di prodotti abbiamo come target una copertura del codice del 50-70% dai test unitari e una copertura del 90% + dai test unitari e dall'automazione dei test combinati. Il tempo tipico previsto per la scrittura di test di unità è di circa 1 giorno per ogni funzione che richiede 3-4 giorni di codifica diretta. Ma ciò può variare con molti fattori.

Il 99% di copertura del codice è eccezionale. I test unitari sono fantastici. Ma il 99% di copertura del codice dai soli test unitari? Trovo difficile credere che puoi ottenere così tanta copertura dai soli test unitari .

Nel caso in cui hai trascorso 3 giorni a scrivere test per una classe che altrimenti ha impiegato 1 giorno per essere implementata. Non hai spiegato il motivo per cui ci è voluto così tanto tempo o condividere alcun codice. Dalla speculazione, immagino che non stavi davvero scrivendo un vero test unitario per la tua classe, ma stavi davvero scrivendo automazione di test . E in realtà non c'è nulla di sbagliato in questo - purché tu riconosca la differenza tra i due diversi tipi di test.

Ma hai detto che i tre giorni di test test sono stati solo per una singola lezione. Forse la classe stessa non è stata progettata per i test unitari. La classe implementa l'interfaccia utente? Networking? File I / O? In tal caso, potresti aver finito per scrivere più codice per testare il runtime Java rispetto alla tua logica aziendale che interagisce con il runtime.

TDD ti fa pensare in termini di interfacce e interfacce alle dipendenze. Quella singola classe che implementa l'interfaccia utente, la rete e il file / io per una singola funzione potrebbe essere meglio suddivisa in più classi: una per la rete, una per il file / io e l'interfaccia utente suddivisa in un modello di controller del visualizzatore di modelli. Quindi è possibile implementare test appropriati per ciascuno con semplici oggetti finti per le dipendenze. Naturalmente, tutto ciò richiede più tempo. Quindi, anziché 1 giorno per codificare e 3 giorni per scrivere i test, questo tipo di progettazione può richiedere 3 giorni di codifica e 1 giorno di test di scrittura. Ma il codice sarà molto meglio gestibile e riutilizzabile.

I test unitari pagano al momento della manutenzione. Se prevedi di avere un'applicazione long life, passerai più tempo a mantenere di quanto pensi ora (se non l'hai ancora provato, rimarrai sorpreso per quanto tempo può durare un progetto di successo)

Quello che vuoi è che se cambi accidentalmente la tua funzionalità i test si interrompono in modo da trovare queste cose il più velocemente possibile. Ai clienti non piace molto quando la funzionalità cambia in modo imprevisto.

Se stai facendo TDD, scriverai i test contemporaneamente al codice, cambiando tra loro ogni pochi minuti (o meno). Non ci sarà alcun tempo distinto speso per i test. L'uso di TDD rende molto più semplice sapere di disporre di una solida copertura dei test.

Se stai testando l'unità dopo il fatto, devi scrivere i test che ti diranno se il codice è rotto a causa di modifiche. Non farei affidamento sulle metriche di copertura qui, ma andrei in base a casi d'uso e parametri alle interfacce pubbliche. Questo alla fine si baserà sul tuo buon gusto ed esperienza.

Se non dedichi tempo ai test, impiegherai ancora più tempo per eseguire il debug nel codice live.
Quindi dedica tutto il tempo necessario ai test, per coprire tutto (o il 99% del codice).

Come altri hanno già notato, dipende in gran parte dal tipo di software. Il rapporto di test / sviluppo 3: 1 menzionato potrebbe essere un po 'troppo per i progetti medi, ma potrebbe essere perfettamente OK per le app mission-critical e potrebbe anche essere troppo piccolo per un sistema critico per la vita.

Allo stesso modo, una copertura del test unitario del 99% è forse troppo da aspettarsi nel caso di un'app media, ma troppo poco per un progetto critico per la vita.

Nella mia esperienza, considerando che una parte significativa del codice di produzione è il codice di gestione degli errori, una copertura dell'80-90% sarebbe sufficiente per la maggior parte delle app, e ciò potrebbe richiedere all'incirca la stessa quantità di tempo impiegato a scrivere unit test del codice di produzione. (Ancora una volta, se uno lavora seriamente in modo TDD, i due sono completamente intrecciati per diventare praticamente un unico compito, quindi si può solo indovinare il rapporto effettivo.)