Esiste un valore nella scrittura di unit test per il codice che funziona già quando si ereditano le applicazioni?

Penso che dovresti scrivere il maggior numero possibile di test per l'applicazione. Ti aiuteranno a imparare il codice base e ti prepareranno per l'eventuale refactoring o nuovo sviluppo.

Ci sono alcuni tipi di test che puoi scrivere in quello scenario, ognuno di loro ha i suoi meriti. Scrivere questi test ti insegnerà moltissimo sull'applicazione con cui hai a che fare.

Prima di tutto, prima di iniziare a scrivere i test per la correttezza, scrivi test che catturano il comportamento corrente , giusto o sbagliato. È una scommessa abbastanza sicura che scoprirai bug in casi d'angolo o parti del codice che non sono stati testati accuratamente eseguendo il programma. Non preoccuparti di cosa dovrebbe fare il codice, semplicemente cattura ciò che fa. Mentre procedete, non preoccupatevi di leggere il codice o di dedicare tempo a capire quale dovrebbe essere l'output. Basta eseguire il test e acquisire quell'output in un assert.

Questo ti darà una solida base di comprensione su come funziona il codice e dove possono essere i principali punti deboli o le aree deboli. Se scopri bug, puoi rivolgerti alle persone con il potere di decidere se valgono la pena o meno e prendere quelle decisioni.

Successivamente, puoi scrivere alcuni test più grandi (in ambito) che coprono parti del codice che potrebbero non essere facilmente testabili da unità ma dove sarebbe comunque importante testare il più possibile i flussi di lavoro. Questi test del flusso di lavoro o test di integrazione , a seconda di come vuoi guardarli, ti daranno una buona base per ridefinire quei flussi di lavoro per renderli più testabili e proteggerti quando è necessario aggiungere una nuova funzionalità che potrebbe influire su un flusso di lavoro esistente.

Nel corso del tempo, creerai una serie di test che è lì per aiutare te o la prossima persona che finisce per ereditare l'applicazione.

Vedo test unitari come specifiche, non semplici test. Nel caso specifico che hai menzionato, il valore reale arriverà quando avrai un test unitario in atto prima di apportare qualsiasi modifica per conformarsi alle nuove specifiche. Se cambierai il codice ereditato, il modo migliore che vedo è di avere dei test unitari per la funzionalità, questo non solo porterà una rete di sicurezza, ma ci aiuterà anche a ottenere maggiore chiarezza su ciò che fa quella particolare unità. Potrebbe anche costringerti a fare qualche ricerca come menzionato da te, che è buono per la comprensione. Quindi il mio obiettivo è di mettere in atto un test dell'unità di un modulo prima che subisca un cambiamento.

 > Is there any value in writing unit tests for code that 
 > already works when inheriting applications?

No . Dalla mia esperienza c'è una cattiva relazione costi / benefici per scrivere test di unità dopo che il codice di produzione è stato scritto perché è abbastanza improbabile / difficile trovare modi per testare il codice in isolamento senza pesanti refactoring. Uno dei vantaggi dello sviluppo basato su test è che si ottiene un codice liberamente accoppiato. Se si scrivono i test in seguito, è probabile che il codice sia strettamente accoppiato.

SÌ potresti scrivere Test di integrazione per l'applicazione per le funzioni in cui prevedi di apportare modifiche. In questo modo puoi regression-test per vedere se le tue modifiche si interrompono.

SÌ dal punto di vista della qualità e dello sviluppatore è prezioso avere test.

NO dal punto di vista del business perché è molto difficile vendere al cliente che hai bisogno di tempo / denaro per non ottenere alcun valore di business reale ma la vaga promessa che i cambiamenti di business non renderanno le cose peggio.

Se possibile, esiste anche un motivo più per scrivere test per codice esistente che "funziona già". Se non ci sono prove, è probabile che il codice sia maturo con gli odori e che possa essere utilizzato un ampio refactoring; la suite di test ti aiuterà a refactoring. Potrebbe persino rivelare che il codice originale non funziona correttamente; Ricordo che una volta scrissi un test per un metodo che generava un rapporto sulle vendite e scoprii che non stava calcolando le cose correttamente, quindi le vendite erano di qualche migliaio di dollari più di quanto non fossero in realtà e nessuno aveva saputo nei cinque anni che il codice era in produzione (per fortuna non era la vera fine finanziaria delle cose, solo una stima del report di vendita).

Ovviamente, questo consiglio si applica solo se in realtà puoi scrivere i test. Nella mia esperienza, un codebase senza test è quasi impossibile per il retrofit dei test perché dovresti riscrivere metà dei moduli di codice per essere abbastanza astratto da supportare prima i test, e non sarai in grado di farlo.

Assolutamente sì , perché i test unitari non dovrebbero verificare la correttezza ma caratterizzare il comportamento effettivo del sistema. Soprattutto con un progetto legacy, molti dei requisiti sono codificati implicitamente nel comportamento effettivo.

Questa caratterizzazione funge da linea di base della funzionalità. Anche se il comportamento non è corretto da un punto di vista aziendale, si preclude il comportamento degradando ulteriormente. Ottenere la trazione in un progetto precedente può essere difficile, e questo ti dà una linea di base in modo che tu possa andare avanti senza peggiorare le cose.

Quindi, scrivi tutti i test unitari che puoi. Per il codice che non può essere testato, rifatta il tuo codice per separare le dipendenze introducendo "cuciture" nel codice - posizioni in cui puoi separare il codice che vuoi testare dal codice che non vuoi testare.

Le idee dei test unitari come test di caratterizzazione e cuciture sono i punti principali di Lavorare efficacemente con il codice legacy di Michael Feathers, un libro che consiglio vivamente.

Ho riflettuto su questo perché ci sono un sacco di documenti non documentati scritti male, ma con codice legacy funzionante nel nostro sistema.

Fai un buon punto:

Should I only bother to unit test if I'm say re-factoring it or should I write unit tests for them whenever I have the time?

Se i requisiti cambiano, penso che sarebbe molto più prezioso scrivere i test delle unità. Altrimenti non mi preoccuperei particolarmente, visto che non saresti in grado di scrivere test adeguati, perché non conosci tutte le condizioni.

whenever I have the time?

Hai tempo in cui viene data la priorità, vero ?, quindi non accadrà mai. :)

Stai cercando di sfruttare aspetti di tale base di codice che non sono stati precedentemente utilizzati in un'applicazione di produzione? Scrivi prima i test unitari per tali scenari. Devi essere in grado di dare la priorità al tuo lavoro qui, e penso che The Art of Unit Testing abbia avuto qualche consiglio in proposito (in particolare come affrontare test di basi di codici legacy).

Non dare per scontato che tutto funzioni solo perché l'applicazione è attiva e in esecuzione ... in genere, il "test del tempo" mostra solo che a) non hai ancora trovato il resto dei difetti o b) le persone chi li ha trovati non li ha denunciati. (O forse entrambi.) E anche il codice che presumibilmente sta funzionando ora potrebbe non funzionare la prossima volta che devi fare un cambiamento.

I test unitari ti danno la certezza che certe funzionalità rimangono intatte, offrendoti anche un modo per dimostrarlo per una ragionevole quantità di casi. Questo è significativamente più prezioso di "colpire e testare questo", anche per una singola correzione di bug. (Fare un giro è più simile a un test di integrazione o di sistema, quindi in questo senso testare manualmente l'app può coprire più di un test unitario, ma è comunque tempo trascorso in modo inefficiente. meglio che eseguirli manualmente.)

Dovresti assolutamente scrivere dei test quando cambi il codice, sia che si tratti di correzione o di refactoring. Potresti fare bene a scrivere test come puoi, se non altro per risparmiare un po 'di tempo la prossima volta che devi correggere un difetto (e ci sarà una prossima volta) ... anche se in questo caso, dovrai Bisogna bilanciare quel tempo con le aspettative delle persone che pretendono che il software sia sempre privo di difetti e che quindi il tempo speso per la manutenzione futura sia "sprecato". (Ciò non significa che dovresti ignorare i programmi attuali, però). Ad un certo punto, se lo fai, avrai una copertura sufficiente per iniziare a dimostrare il valore del testing sulle applicazioni legacy e questo potrebbe aiutarti a spendere quella volta per le app future, che dovrebbero liberare tempo da dedicare allo sviluppo produttivo.

Dal mio cuore di lala-land, dirò di si e non solo quello, ma lo modifico, lo refactoring e continuo a testare, ma assicurati di non rimanere indietro in altri progetti importanti. Come programmatore di lavoro, se il tuo lavoro è a rischio o se un manager ti ha detto di diventare proprietario, allora sì. Se il team o l'azienda potrebbero soffrire, negoziare con il proprio responsabile per fargli sapere che è necessario fare test per mantenere l'azienda dal disastro. Se lui dice non ti preoccupare, allora sei fuori dal guaio (non necessariamente, delegazione di colpa è un'abilità di gestione, quindi assicurati di essere fuori dai guai ... davvero!)

Buona fortuna!