quanto tempo spendi per il test dell'unità?

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

• Dimensioni del prodotto (più grande è il progetto, maggiore è la necessità di includere almeno alcuni test delle unità)
• Livello di qualità richiesto (Se stai mettendo rapidamente insieme il software che deve essere il più veloce possibile e alcuni bug minori sono accettabili, allora potresti essere obbligato a saltare alcuni test come test delle unità)
• Tipo di prodotto (le interfacce utente possono essere testate su unità, ma a volte è più semplice saltare il test dell'unità su sezioni di GUI pesanti e invece testare manualmente)
• La tua capacità di codifica / cronologia (che tipo di bug crei normalmente? Sono cose che il test unitario normalmente cattura o cose che normalmente si trovano in un altro tipo di test. Sapere questo potrebbe spingerti a fare più o meno test unitari)

Nel nostro gruppo di prodotti il nostro obiettivo è una copertura del 50-70% del codice rispetto ai test unitari e una copertura del 90% + dai test unitari e dall'automazione dei test messi insieme. Il tempo tipico previsto per la scrittura dei test unitari è di circa 1 giorno per ogni funzione che richiede 3-4 giorni di codifica con la testa in giù. Ma questo può variare con molti fattori.

La copertura del codice del 99% è eccezionale. I test unitari sono fantastici. Ma la copertura del codice del 99% dal solo test unitario? Trovo così difficile credere che tu possa ottenere tutta questa copertura dai test delle unità da solo.

Per il caso in cui hai trascorso 3 giorni a scrivere test per una classe che altrimenti richiedeva un giorno di implementazione. Non hai elaborato il motivo per cui ci è voluto tanto tempo o condividere un codice. Dalla speculazione, immagino che non stavi davvero scrivendo un vero test unitario per la tua classe, ma in realtà stavi scrivendo automazione dei test . E in realtà non c'è niente 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 di scrittura erano solo per una singola classe. Forse la classe stessa non è stata progettata per i test unitari. La classe implementa l'interfaccia utente? Networking? File I / O? In tal caso, è possibile che si sia finito a scrivere più codice per testare il runtime Java rispetto alla logica aziendale che interagisce con il runtime.

TDD ti fa pensare in termini di interfacce e interfacce alle dipendenze. Quella singola classe che implementa UI, networking e file / io per una singola funzione potrebbe essere meglio divisa in più classi: una per il networking, una per il file / io e l'interfaccia utente interrotta in una progettazione modello-visualizzatore-controller. Quindi è possibile implementare test appropriati per ciascuno con semplici oggetti mock per le dipendenze. Naturalmente, tutto questo richiede più tempo. Quindi, piuttosto che 1 giorno per il codice e 3 giorni per scrivere i test, questo tipo di progettazione potrebbe richiedere 3 giorni di codice e 1 giorno di test di scrittura. Ma il codice sarà molto più gestibile e riutilizzabile.

I test unitari si ripagano al momento della manutenzione. Se hai intenzione di avere una lunga esperienza di vita passerai più tempo a mantenere di quanto pensi ora (se non l'hai ancora provato, rimarrai sorpreso per quanto tempo potrebbe vivere un progetto di successo)

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

Se stai facendo TDD, scriverai i test contemporaneamente al codice, passando da uno all'altro ogni pochi minuti (o meno). Non ci sarà alcun tempo distinto per i test. L'uso di TDD rende molto più facile sapere di avere una solida copertura di test.

Se sei un test unitario dopo il fatto, devi scrivere i test che ti diranno se il codice è rotto a causa di cambiamenti. Non farei affidamento sulle metriche di copertura qui, ma andrei basato su casi d'uso e parametri alle interfacce pubbliche. Questo alla fine si baserà sul tuo buon gusto ed esperienza.

Come altri già notato, dipende in gran parte dal tipo di software. Il rapporto di 3: 1 test / tempo di sviluppo che hai citato potrebbe essere un po 'eccessivo per i progetti medi, ma potrebbe essere perfettamente OK per le app mission critical e potrebbe essere anche troppo poco per un sistema vitale.

Il 99% di copertura del test unitario è forse troppo da prevedere nel caso di un'app media, ma troppo poco per un progetto vitale.

In base alla 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 lo stesso tempo impiegato per scrivere i test unitari come codice di produzione. (Poi di nuovo, se si lavora seriamente in modalità TDD, i due sono completamente intrecciati per diventare praticamente un unico compito, quindi si può solo ipotizzare il rapporto effettivo.)

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