Codice di correzione dei bug senza test

Sebbene questo metodo sia migliore del semplice avvio del codice, non impedisce di rompere le funzionalità esistenti. E questo è normalmente il più grande pericolo quando si corregge un bug.

Se vuoi davvero essere sicuro, non c'è modo di aggiungere i tutti test richiesti per il modulo su cui stai lavorando. Tuttavia è molto improbabile che tu abbia le risorse per farlo. Pertanto è richiesta una sorta di compromesso. Non esiste una ricetta semplice. Meno capisci il codice esistente, più è complesso e più alti sono gli standard di qualità da soddisfare, maggiore è lo sforzo richiesto per implementare i test.

A parte questo, proverei a fare un refactoring del codice esistente prima di modificarne la funzionalità.

Dipende dal tipo di codice.

Se la funzione è strettamente correlata e non ha effetti collaterali, puoi scrivere test completi solo per quella funzione ed essere sicuro di non aver rotto nulla.

Se la funzione accede a variabili globali o altrimenti cambia stato, allora è molto più difficile. Dovrai o rivedere attentamente il codice per determinare cosa potrebbe essere interessato. Puoi anche utilizzare gli strumenti per dipendenze della mappa per ottenere una visualizzazione visiva di come le tue modifiche possono propagare la logica cambia in tutto il codice base. Potresti quindi dover testare funzioni che altrimenti sembrerebbero non correlate alle tue modifiche.

Sì, questo è un ottimo approccio quando si risolvono i bug in modalità manutenzione. In questo modo, puoi almeno dimostrare che il bug è stato corretto, e finire con un test di regressione "gratuito" - finché hai questo test, non dovrai mai correggere lo stesso bug due volte.

Scrivere un test adatto può tuttavia diventare piuttosto difficile quando il sistema non è stato progettato per la testabilità, ad es. se non è stata utilizzata l'iniezione di dipendenza. Ciò non rende necessariamente i test impossibili, li rende solo più costosi e più fragili. In questi casi, potrebbe essere utile eseguire un refactoring molto accurato per introdurre cuciture nel design in cui è possibile applicare i test.

In assenza di una suite di test completa, una buona documentazione e una buona conoscenza del dominio, è impossibile garantire che il tuo bugfix non rotti qualcos'altro. È bene essere consapevoli di questo rischio, ma non può essere mitigato. Dato che sei a conoscenza di questo rischio, proverai a limitare le correzioni dei bug alla più piccola area di codice possibile. Cercare di lasciare il codice migliore di quello che hai trovato è una nobile causa, ma è rischioso se non comprendi pienamente tutte le implicazioni di questo codice.

Idealmente, dovresti anche eseguire la versione fissa insieme alla versione interrotta per rilevare le modifiche nell'output o nel comportamento che non avevi intenzione, ma probabilmente non è fattibile per sistemi complessi.

Vale anche la pena sottolineare che i bug tendono a raggrupparsi. Se hai tempo, chiedi: perché è stato introdotto questo bug? Qual è la causa principale? Potrebbe aver causato problemi simili qui intorno?

Con una comprensione sufficiente, può essere meglio intraprendere un refactoring più completo di un modulo. Per esempio. una volta stavo sottoponendo a test una piccola funzione di analisi. La causa principale non era che l'algoritmo di analisi era difettoso, ma il modello di dati dell'output. Ora che ho capito come non rappresentare questo tipo di dati, potrei completamente riscrivere quella parte del codice ed eliminare un'intera classe di possibili problemi. Un'altra volta, si è scoperto che un modulo molto difettoso era presente solo per ragioni storiche e non era più utilizzato realmente. La sua eliminazione è stata molto più produttiva rispetto al tentativo di correggere ogni singolo problema.