Avendo appena letto i primi quattro capitoli di Refactoring: Improving the Design of Existing Code, ho intrapreso il mio primo refactoring e quasi immediatamente sono arrivato a un posto di blocco. Deriva dal requisito che prima di iniziare il refactoring, dovresti sottoporre i test unitari al codice precedente. Ciò ti consente di essere sicuro che il tuo refactoring non ha modificato il codice originale (solo come lo ha fatto).Rifacimento pratico con test unitari
Quindi la mia prima domanda è questa: come faccio a testare un metodo in un codice legacy? Come posso mettere un test unitario attorno a un metodo di 500 linee (se sono fortunato) che non fa un solo compito? Mi sembra che dovrei refactoring il mio codice legacy solo per renderlo unit-testabile.
Qualcuno ha esperienza di refactoring utilizzando i test unitari? E se sì, hai qualche esempio pratico che puoi condividere con me?
La mia seconda domanda è piuttosto difficile da spiegare. Ecco un esempio: voglio refactoring un metodo legacy che popola un oggetto da un record del database. Non dovrei scrivere un test unitario che paragona un oggetto recuperato usando il vecchio metodo, con un oggetto recuperato usando il mio metodo refactored? Altrimenti, come potrei sapere che il mio metodo refactored produce gli stessi risultati del vecchio metodo? Se è vero, allora quanto tempo lascerò il vecchio metodo deprecato nel codice sorgente? Lo faccio appena dopo aver provato alcuni record diversi? O, devo tenerlo in giro per un po 'nel caso in cui si verifichi un bug nel mio codice refactored?
Infine, poiché un paio di persone hanno chiesto ... il codice legacy è stato originariamente scritto in VB6 e quindi trasferito su VB.NET con modifiche minime dell'architettura.
Ottima domanda. Puoi anche provare Katas, che ti aiuta a prendere l'abitudine di scrivere un buon codice e come scrivere codice unitario testato: https://github.com/garora/TDD-Katas –