Quanto tempo dovremmo generalmente dedicare alla scrittura di unit test per una nuova funzionalità o correzione di bug?


9

Quando devo implementare una nuova funzionalità o correggere un bug, di solito provo a ricreare la situazione con un test. A volte trascorro circa 3 ore trovando infissi e scrivendo il test. L'implementazione della funzione effettiva o la correzione dei bug richiede meno di 1 ora.

Qualcun altro spende almeno 3 volte più a lungo per scrivere un test rispetto all'implementazione effettiva di una funzione o alla correzione di un bug? Qual è il rapporto accettabile tra il tempo impiegato per scrivere test e scrivere codice?


2
Pensala in questo modo: la correzione del bug richiederebbe meno di un'ora se non avessi un test per confermare che esistesse, molto meno è stato risolto?
Michael K,

2
Rispondi al titolo della domanda: tutto il tempo necessario.
Marcelo,

3
Penso che l'obbedienza servile ai principi del TDD, indipendentemente dal costo o dal valore commerciale, sia sempre la risposta giusta.
Jeremy,

Come gestisci il caso in cui il tuo manager desidera che la correzione sia pubblicata al più presto e non può aspettare un giorno in più per testare completamente l'implementazione?
Thierry Lam,

2
Di solito spiego il costo di non fare il test. Cioè, posso spedire la correzione ora, ma se non scriviamo il test, dovremo rifare tutto da capo in seguito. Alcune volte sono d'accordo con quel costo futuro, ma di solito scriviamo i test.
Christopher Bibbs,

Risposte:


12

Varia in base alla complessità del bug o della funzionalità. Ricordo un progetto che una volta aveva una stima tiem di sviluppo di 1,5 settimane ... e una stima di test di 3 mesi. La modifica del codice era piccola, una manciata di linee qua e là, ma ha influenzato una serie di componenti di un sistema assicurativo in diversi modi, quindi è stato necessario testarlo a fondo. Un'altra volta c'è stato un bug che ha coinvolto una parentesi nel posto sbagliato. Ci sono voluti 2 ore per trovarlo, 2 secondi per risolverlo, ma circa una settimana per testare decine di scenari che potrebbero essere stati influenzati dal cambio di logica.

In generale, non mi preoccupo del rapporto tra il tempo impiegato per la codifica e il tempo impiegato per i test perché non c'è modo di essere precisi. Trovo che in alcuni progetti appaia un rapporto relativo al progetto che di solito è standard (rispetto al progetto), ma anche in questo caso può cambiare in seguito.

Trascorrere tutto il tempo necessario per dire con sicurezza che il codice funziona correttamente.


6

Che ne dici di passare abbastanza tempo a scrivere i test fino a quando non hai dimostrato che la funzione funziona come previsto, o che il bug è stato corretto correttamente.

Ogni situazione sarà diversa; non può esserci un qualche tipo di rapporto. Alcuni test impiegheranno un decimo del tempo rispetto all'implementazione, altri impiegheranno centinaia di volte tanto tempo.


Questa è la vera risposta
DJClayworth,

4

Una volta ho fatto un tentativo dopo aver introdotto i test unitari in un progetto. Il risultato: il tempo impiegato per scrivere i test è stato di nuovo circa il 40% tanto quanto il tempo impiegato per l'implementazione. Ma non miravamo a una copertura completa lì, ed era un progetto consolidato con una struttura e convenzioni forti.



0

Stai contando giusto? Per fare una contabilità accurata di quanto tempo dedichi ai test devi scrivere il codice senza il test.

Se ti ci sono volute davvero tre ore per scrivere il test e uno per scrivere il codice per farlo passare, potresti scoprire che ci vogliono più di 5 ore per correggere lo stesso bug senza scrivere test.

Sì, molto spesso trascorro molto più tempo sul test rispetto all'effettivo codice di correzione.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.