Differenza di tempo tra lo sviluppo con unit test e nessun test

Sono uno sviluppatore solista con un ambiente di lavoro piuttosto limitato nel tempo in cui il tempo di sviluppo varia generalmente da 1 a 4 settimane per progetto, a seconda delle esigenze, dell'urgenza o di entrambi. In qualsiasi momento gestisco circa 3-4 progetti, alcuni con tempistiche che si sovrappongono.

Presumibilmente, la qualità del codice ne risente. Inoltre non ho test formali; di solito scende a camminare attraverso il sistema fino a quando non si rompe in qualche modo. Di conseguenza, una notevole quantità di bug sfugge alla produzione, che devo correggere e, a sua volta, arresta i miei altri progetti.

È qui che entra in gioco il test unitario. Se fatto bene, dovrebbe contenere al minimo i bug, figuriamoci quelli che sfuggono alla produzione. D'altra parte, scrivere test può richiedere molto tempo, il che non suona bene con progetti a tempo limitato come il mio.

La domanda è: quanta differenza di tempo scriverebbe il codice unit-test su un codice non testato, e in che modo la differenza di tempo si allarga con l'ampliamento dell'ambito del progetto?

Più tardi esegui il test, più costa scrivere i test.

Più a lungo vive un bug, più costoso è riparare.

La legge dei rendimenti decrescenti ti consente di metterti alla prova nell'oblio cercando di assicurarti che non ci siano bug.

Buddha insegnò la saggezza della via di mezzo. I test sono buoni. C'è una cosa troppo buona. La chiave è riuscire a capire quando sei sbilanciato.

Ogni riga di codice che scrivi senza test avrà costi significativamente maggiori per l'aggiunta di test più tardi rispetto a se avessi scritto i test prima di scrivere il codice.

Ogni riga di codice senza test sarà significativamente più difficile da eseguire il debug o riscrivere.

Ogni test che scrivi richiederà tempo.

Ogni bug richiederà tempo per essere risolto.

I fedeli ti diranno di non scrivere una singola riga di codice senza prima aver scritto un test fallito. Il test ti assicura di ottenere il comportamento che ti aspetti. Ti consente di modificare rapidamente il codice senza preoccuparti di influire sul resto del sistema poiché il test dimostra che il comportamento è lo stesso.

È necessario valutare tutto ciò rispetto al fatto che i test non aggiungono funzionalità. Il codice di produzione aggiunge funzionalità. E le caratteristiche sono ciò che paga le bollette.

In termini pragmatici, aggiungo tutti i test con cui posso cavarmela. Ignoro i commenti a favore di guardare i test. Non mi fido nemmeno del codice per fare ciò che penso faccia. Mi fido dei test. Ma sono stato conosciuto per lanciare occasionalmente grandine Mary e avere fortuna.

Tuttavia, molti programmatori di successo non fanno TDD. Ciò non significa che non testino. Semplicemente non insistono ossessivamente sul fatto che ogni riga di codice abbia un test automatico contro di essa. Anche lo zio Bob ammette di non testare la sua interfaccia utente. Insiste anche sul fatto che si sposta tutta la logica dall'interfaccia utente.

Come metafora del calcio (ovvero football americano) TDD è un buon gioco di base. Test manuali solo in cui si scrive una pila di codice e si spera che funzioni è un gioco di passaggio. Puoi essere bravo in entrambi. La tua carriera non farà i playoff a meno che tu non possa fare entrambe le cose. Non farà il superbowl fino a quando non imparerai quando sceglierne uno. Ma se hai bisogno di una spinta in una direzione particolare: le chiamate degli ufficiali vanno contro di me più spesso quando passo.

Se vuoi provare TDD, ti consiglio vivamente di esercitarti prima di provare a farlo sul posto di lavoro. Il TDD fatto a metà, metà di cuore e metà di culo è una grande ragione per cui alcuni non lo rispettano. È come versare un bicchiere d'acqua in un altro. Se non ti impegni e lo fai rapidamente e completamente finirai per gocciolare acqua su tutto il tavolo.

Concordo con il resto delle risposte ma per rispondere direttamente alla domanda qual è la differenza di tempo .

Roy Osherove nel suo libro The Art of Unit Testing, Seconda Edizione, pagina 200, ha condotto un case study sull'implementazione di progetti di dimensioni simili con team simili (per quanto riguarda le competenze) per due diversi clienti in cui un team ha eseguito i test mentre l'altro no.

I suoi risultati furono così:

Quindi alla fine di un progetto ottieni sia meno tempo che meno bug. Questo ovviamente dipende da quanto è grande un progetto.

C'è solo uno studio che conosco che lo ha studiato in un "ambiente del mondo reale": Realizzare il miglioramento della qualità attraverso lo sviluppo test-driven: risultati ed esperienze di quattro team industriali . È costoso farlo in modo sensato, dal momento che in pratica significa che è necessario sviluppare lo stesso software due volte (o idealmente anche più spesso) con team simili, e poi buttare via tutto tranne uno.

I risultati dello studio sono stati un aumento del tempo di sviluppo tra il 15% -35% (che non è affatto vicino alla cifra 2x che viene spesso citata dai critici TDD) e una diminuzione della densità del difetto di pre-rilascio dal 40% al 90% (! ). Si noti che tutti i team non avevano alcuna esperienza precedente con TDD, quindi si potrebbe presumere che l'aumento del tempo possa almeno in parte attribuito all'apprendimento, e quindi diminuirebbe ulteriormente nel tempo, ma questo non è stato valutato dallo studio.

Nota che questo studio riguarda il TDD e la tua domanda riguarda i test unitari, che sono cose molto diverse, ma è il più vicino che ho potuto trovare.

Fatto bene, lo sviluppo con i test unitari può essere più veloce anche senza considerare i benefici dei bachi extra.

Il fatto è che non sono un programmatore abbastanza bravo da far funzionare il mio codice non appena viene compilato. Quando scrivo / modifico il codice, devo eseguirlo per assicurarmi che faccia quello che pensavo facesse. In un progetto, questo tendeva a sembrare:

1. Modifica codice
2. Compilare l'applicazione
3. Esegui applicazione
4. Accedi all'applicazione
5. Apri una finestra
6. Seleziona un elemento da quella finestra per aprire un'altra finestra
7. Imposta alcuni controlli in quella finestra e fai clic su un pulsante

E naturalmente, dopo tutto ciò, di solito ci sono voluti alcuni viaggi di andata e ritorno per farlo davvero bene.

Ora, cosa succede se sto usando i test unitari? Quindi il processo appare più simile a:

1. Scrivi un test
2. Esegui i test, assicurati che fallisca nel modo previsto
3. Scrivi il codice
4. Eseguire di nuovo i test, vedere che passa

Questo è più facile e veloce quindi testare manualmente l'applicazione. Devo ancora eseguire manualmente l'applicazione (quindi non sembro sciocca quando accendo un lavoro che in realtà non funziona affatto), ma per la maggior parte ho già elaborato i nodi e sono solo verificando a quel punto. In realtà in genere rendo ancora più stretto questo ciclo usando un programma che esegue automaticamente i miei test quando salvo.

Tuttavia, questo dipende dal funzionamento in una base di codice test-friendly. Molti progetti, anche quelli con molti test, rendono difficili i test di scrittura. Ma se ci lavori, puoi avere una base di codice che è più facile da testare tramite test automatici che con test manuali. Come bonus, puoi mantenere i test automatizzati e continuare a eseguirli per prevenire regressioni.

Nonostante ci siano già molte risposte, sono in qualche modo ripetitive e vorrei prendere una virata diversa. I test unitari sono preziosi, se e solo se , aumentano il valore aziendale . Testare per motivi di test (test banali o tautologici), o per colpire una metrica arbitraria (come la copertura del codice), è una programmazione cargo-cult.

I test sono costosi, non solo nel tempo necessario per scriverli, ma anche per la manutenzione. Devono essere sincronizzati con il codice che testano o sono privi di valore. Per non parlare del costo del tempo per eseguirle su ogni modifica. Questo non è un affare (o una scusa per non fare quelli veramente necessari), ma deve essere preso in considerazione per l'analisi costi-benefici.

Quindi la domanda da porsi quando si decide se (o che tipo) testare una funzione / metodo, chiedersi "quale valore per l'utente finale sto creando / salvaguardando con questo test?". Se non riesci a rispondere a questa domanda, a partire dalla cima della tua testa , allora quel test probabilmente non vale il costo di scrivere / mantenere. (o non capisci il dominio del problema, che è un problema waaaay più grande della mancanza di test).

http://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf

Dipende dalla persona, nonché dalla complessità e dalla forma del codice con cui stai lavorando.

Per me, sulla maggior parte dei progetti, la scrittura di unit test significa che il lavoro è più veloce del 25%. Sì, anche includendo il tempo per scrivere i test.

Perché il fatto è che il software non viene eseguito quando si scrive il codice. Viene eseguito quando lo spedisci al cliente e ne sono contenti. I test unitari sono di gran lunga il modo più efficiente che conosco per catturare la maggior parte dei bug, isolare la maggior parte dei bug per il debug e ottenere la certezza che il codice sia buono. Devi comunque fare queste cose , quindi fallo bene.

La domanda è: quanta differenza di tempo scriverebbe il codice unit-test su un codice non testato, e in che modo la differenza di tempo si allarga con l'ampliamento dell'ambito del progetto?

Il problema peggiora con l'aumentare dell'età del progetto: perché ogni volta che aggiungi nuove funzionalità e / o ogni volta che rifletti l'implementazione esistente, dovresti ripetere il test di ciò che è stato precedentemente testato per assicurarti che funzioni ancora. Pertanto, per un progetto di lunga durata (pluriennale), potrebbe essere necessario non solo testare la funzionalità, ma riprovarla 100 volte e più. Per questo motivo potresti trarre vantaggio dall'avere test automatici . Tuttavia, l'IMO è abbastanza buono (o addirittura migliore) se si tratta di test di sistema automatizzati, piuttosto che di test di unità automatizzati.

Un secondo problema è che i bug possono essere più difficili da trovare e correggere se non vengono catturati in anticipo. Ad esempio se c'è un bug nel sistema e so che funzionava perfettamente prima che tu apportassi la tua ultima modifica, quindi concentrerò la mia attenzione sulla tua ultima modifica per vedere come potrebbe aver introdotto il bug. Ma se non so che il sistema funzionava prima che tu apportassi la tua ultima modifica (perché il sistema non era stato testato correttamente prima della tua ultima modifica), allora il bug potrebbe essere ovunque.

Quanto sopra si applica in particolare al codice deep e meno al codice shallow, ad esempio l'aggiunta di nuove pagine Web in cui è improbabile che nuove pagine influiscano sulle pagine esistenti.

Di conseguenza, una notevole quantità di bug sfugge alla produzione, che devo correggere e, a sua volta, arresta i miei altri progetti.

Nella mia esperienza sarebbe inaccettabile, quindi stai facendo la domanda sbagliata. Invece di chiedere se i test renderebbero lo sviluppo più veloce, dovresti chiedere cosa renderebbe lo sviluppo più privo di bug.

Una domanda migliore potrebbe essere:

• Il test unitario è il giusto tipo di test, che è necessario per evitare la "notevole quantità di bug" che ha prodotto?
• Esistono altri meccanismi di controllo / miglioramento della qualità (oltre ai test unitari) da raccomandare o invece?

L'apprendimento è un processo in due fasi: impara a farlo abbastanza bene, quindi impara a farlo più rapidamente.

Alcuni aspetti da considerare, non menzionati nelle altre risposte.

• Vantaggi / costi aggiuntivi dipendono dall'esperienza con la scrittura di unittests
  • con il mio primo progetto di unit test i costi extra sono triplicati perché ho dovuto imparare molto e ho fatto molti errori.
  • dopo 10 anni di esperienza con tdd ho bisogno del 25% di tempo in più per scrivere i test in anticipo.
• con più moduli tdd è ancora necessario eseguire test di gui manuali e test di integrazione
• tdd funziona solo quando fatto dall'inizio.
  • applicare tdd a un progetto esistente e cresciuto è costoso / difficile. Puoi invece implementare test di regressione.
• i test automatici (unittest e altri tipi di test) richiedono costanti di manutenzione per farli funzionare.
  • aver creato test tramite copia e incolla può rendere costoso testcode-maintanace.
  • con la crescente esperienza testcode diventa più modulare e più facile da mantenere.
• con l'esperienza crescente avrai la sensazione quando vale la pena creare test automatizzati e quando no.
  • ad esempio, non ci sono grandi vantaggi per i getter / setter / wrapper semplici unittest
  • non scrivo test automatizzati tramite la GUI
  • mi occupo che il businesslayer possa essere testato

Sommario

Quando si inizia con tdd, è difficile raggiungere lo stato "più vantaggi del costo" purché ci si trovi in ​​un "ambiente di lavoro limitato nel tempo", specialmente se ci sono "gestori intelligenti" che ti dicono di "sbarazzarti del costoso, inutile test roba "

Nota: con "unit testing" intendo "test di moduli isolati".

Nota: con "test di regressione" intendo

• scrivere del codice che produce del testo di output.
• scrivere un codice di "test di regressione" che verifica che il risultato della generazione sia sempre lo stesso.
• il test di regressione ti fa sapere ogni volta che cambia il risultato (che potrebbe essere ok o un indicatore per un nuovo bug)
• l'idea di "test di regressione" è simile ai test di approvazione
  • ... scattare un'istantanea dei risultati e confermare che non sono cambiati.

I programmatori, come le persone che si occupano della maggior parte delle attività, sottovalutano il tempo effettivamente necessario per completarla. Con questo in mente, passare 10 minuti per scrivere un test può essere considerato come il tempo che uno avrebbe potuto spendere scrivendo tonnellate di codice quando in realtà, avresti trascorso quel tempo a trovare lo stesso nome di funzione e gli stessi parametri che hai fatto durante il test . Questo è uno scenario TDD.

Non scrivere test, è come avere una carta di credito; tendiamo a spendere di più o scrivere più codice. Più codice ha più bug.

Invece di decidere di avere una copertura totale del codice o nessuna, suggerisco di concentrarti sulla parte critica e complicata della tua applicazione e fare dei test lì. In un'app bancaria, questo potrebbe essere il calcolo degli interessi. Uno strumento diagnostico del motore può avere protocolli di calibrazione complessi. Se hai lavorato su un progetto, probabilmente sai cos'è e dove sono i bug.

Inizia lentamente. Costruisci un po 'di fluidità prima di giudicare. Puoi sempre smettere.

C'è stata una lunga storia di programmatori che promuovono TDD e altre metodologie di test, non ricordo i loro argomenti e sono d'accordo con loro, ma qui ci sono altre cose da considerare che dovrebbero sfumare un po ':

• Il test non è altrettanto conveniente ed efficiente a seconda del contesto. Sviluppo software Web, dimmi se hai un programma per testare l'intera UI ... in questo momento sto programmando macro Excel, dovrei davvero sviluppare un modulo di test in VBA?
• Scrivere e mantenere il software di test è un vero lavoro che conta a breve termine (ripaga a lungo termine). Scrivere test pertinenti è anche una competenza da ottenere
• Lavorare come un team e lavorare da soli, non hanno gli stessi requisiti di test perché nel team è necessario convalidare, comprendere e comunicare il codice che non è stato scritto.

Direi che il test è buono, ma assicurati di testare presto e testare dove si trova il guadagno.

Un vantaggio spesso trascurato di TDD è che i test fungono da salvaguardia per assicurarsi di non introdurre nuovi bug quando si effettua una modifica.

L'approccio TDD richiede indubbiamente più tempo inizialmente, ma il punto da asporto è scrivere meno codice, il che significa che meno cose vanno male. Tutte quelle campane e fischietti che spesso includi, ovviamente, non entreranno nella base di codice.

C'è una scena nel film Pesce spada in cui se la memoria serve, un hacker deve lavorare con una pistola in testa ed essere erm ... altrimenti distratto. Il punto è che è molto più facile lavorare quando il tuo spazio di testa è nel codice e hai tempo dalla tua parte piuttosto che mesi lungo la linea con un cliente che ti urla e altre priorità vengono schiacciate.

Gli sviluppatori comprendono che correggere i bug in un secondo momento è più costoso, ma capovolgerlo sulla sua testa. Se potessi essere pagato $ 500 al giorno per codificare il modo in cui codifichi ora o $ 1000 se scrivessi in un modo TDD, ti morderesti la mano della persona che ti fa la seconda offerta. Prima smetti di vedere i test come un lavoro ingrato e lo vedi come un risparmio di denaro, tanto meglio sarai.

Posso riferirmi alla tua esperienza - la nostra base di codice non aveva quasi test ed era per lo più non verificabile. Ci sono voluti letteralmente anni per sviluppare qualcosa e correggere i bug di produzione ha impiegato del tempo prezioso con nuove funzionalità.

Per una riscrittura parziale, ho promesso di scrivere test per tutte le funzionalità di base. All'inizio, ci è voluto molto più tempo e la mia produttività ha sofferto notevolmente, ma in seguito la mia produttività è stata migliore che mai.

Parte di quel miglioramento era che avevo meno bug di produzione che a loro volta portavano a meno interruzioni -> Mi concentrai meglio in qualsiasi momento.

Inoltre, la capacità di testare E il codice di debug in isolamento paga davvero: una suite di test è di gran lunga superiore a un sistema che non può essere eseguito il debug se non con la configurazione manuale, ad esempio l'avvio dell'app e la navigazione sullo schermo e fare qualcosa ... forse alcune decine di volte

Ma nota che all'inizio c'è un calo della produttività, quindi inizia a imparare i test su alcuni progetti in cui la pressione del tempo non è già pazza. Inoltre, prova ad avviarlo su un progetto greenfield, il codice legacy di unit test è molto difficile e aiuta quando sai come appare una buona suite di test.

Solo per integrare le risposte precedenti: ricorda che il test non è uno scopo in sé. Lo scopo di eseguire test è che l'applicazione si comporti come previsto attraverso l'evoluzione, in contesti imprevisti, ecc.

Pertanto, scrivere test non significa dimostrare tutti i comportamenti di tutti gli endpoint di un'entità. Questo è un errore comune. Molti sviluppatori pensano di dover testare tutte le funzioni / oggetti / metodi / proprietà / ecc. Ciò comporta un elevato carico di lavoro e un sacco di codice e test irrilevanti. Questo approccio è comune nei grandi progetti, in cui la maggior parte degli sviluppatori non è consapevole del comportamento olistico, ma può solo vedere il proprio dominio di interazione.

L'approccio giusto quando si ha a che fare con risorse e test sparsi è piuttosto ovvio e di buon senso, ma non comunemente formalizzato: investire testando le risorse di sviluppo prima su funzionalità di alto livello e gradualmente scendendo nelle specificità . Ciò significa che ad un certo punto, come sviluppatore solitario, non ti concentreresti solo sul test unitario, ma su funzionale / integrazione / ecc. test e in base alle tue risorse di tempo, gradualmente nelle principali funzioni unitarie, come pianificheresti e considereresti. I test di alto livello forniranno le informazioni necessarie per affrontare i test di basso livello / unitari e per pianificare la strategia di sviluppo dei test in base alle risorse disponibili.

Ad esempio, si desidera testare prima una catena di elaborazione come una scatola nera. Se scopri che alcuni membri della catena falliscono a causa del comportamento non considerato una condizione estrema, scrivi i test che garantiscono la funzionalità non solo su questo membro ma anche su altri. Quindi consegna. Per il ciclo successivo, si rileva che a volte la rete non funziona. Quindi scrivi test che risolvono tale problema sui moduli che potrebbero essere vulnerabili. E così via.