Refactoring per la testabilità su un sistema esistente

Question

Sono entrato a far parte di un team che lavora su un prodotto.Questo prodotto è in circolazione da circa 5 anni e utilizza ASP.NET WebForms.La sua architettura originale è sbiadita nel tempo e le cose sono diventate relativamente disorganizzate in tutta la soluzione.Non è affatto terribile, ma sicuramente può essere utile un po' di lavoro;sapete tutti cosa intendo.

Ho eseguito alcuni refactoring da quando sono entrato nel team di progetto circa 6 mesi fa.Alcuni di questi refactoring sono semplici, il metodo Extract, il metodo Pull Up, ecc.Alcuni dei refactoring sono più strutturali.Questi ultimi cambiamenti mi rendono nervoso poiché non esiste una suite completa di test unitari per accompagnare ogni componente.

L'intero team è d'accordo sulla necessità di apportare modifiche strutturali attraverso il refactoring, ma il nostro Project Manager ha espresso alcune preoccupazioni sul fatto che non disponiamo di test adeguati per effettuare refactoring con la certezza che non stiamo introducendo bug di regressione nel sistema.Vorrebbe che prima scrivessimo più test (rispetto all'architettura esistente), quindi eseguissimo i refactoring.La mia tesi è che la struttura delle classi del sistema è troppo strettamente accoppiata per scrivere test adeguati e che utilizzare un approccio più basato sui test mentre eseguiamo i nostri refactoring potrebbe essere migliore.Ciò che intendo con questo non è scrivere test sui componenti esistenti, ma scrivere test per requisiti funzionali specifici, quindi eseguire il refactoring del codice esistente per soddisfare tali requisiti.Questo ci consentirà di scrivere test che probabilmente avranno una maggiore longevità nel sistema, piuttosto che scrivere un mucchio di test "usa e getta".

Qualcuno ha qualche esperienza su quale sia la migliore linea d'azione?Ho la mia opinione, ma mi piacerebbe sentire qualche input dalla community.

Answer 1

Le preoccupazioni del tuo PM sono valide: assicurati di testare il tuo sistema prima di effettuare qualsiasi refactoring importante.

Consiglio vivamente di procurarsi una copia del libro di Michael Feather Lavorare in modo efficace con il codice legacy (per "Legacy Code" Feathers indica qualsiasi sistema che non sia adeguatamente coperto dai test unitari).Questo è pieno zeppo di buone idee su come abbattere quegli accoppiamenti e dipendenze di cui parli, in un modo sicuro che non rischierà di introdurre bug di regressione.

Buona fortuna con il programma di refactoring;nella mia esperienza è un processo divertente e catartico da cui puoi imparare molto.

Answer 2

Puoi rifattorizzare in parallelo?Ciò che intendo è riscrivere i pezzi di cui si desidera eseguire il refactoring utilizzando TDD, ma lasciare in posizione la base di codice esistente.Quindi eliminare gradualmente il codice esistente quando i nuovi test soddisfano le esigenze del tuo PM?

Answer 3

Vorrei anche dare un suggerimento per visitare il Refactoring sito web di Martin Fowler.Ha letteralmente scritto il libro su queste cose.

Per quanto riguarda l'introduzione dei test unitari nell'equazione, il metodo migliore che ho trovato è trovare un componente di primo livello e identificare tutte le dipendenze esterne che ha su oggetti concreti e sostituirle con interfacce.Una volta fatto ciò, sarà molto più semplice scrivere test unitari rispetto alla base di codice e potrai farlo un componente alla volta.Ancora meglio, non dovrai buttare via nessun test unitario.

Il test unitario ASP.Net può essere complicato, ma esistono numerosi framework che ne semplificano l'esecuzione. ASP.Net MVC, E WCSF per dirne alcuni.

Answer 4

Lancio solo una seconda raccomandazione per Lavorare in modo efficace con il codice legacy, un libro eccellente che mi ha davvero aperto gli occhi sul fatto che quasi tutti i codici vecchi, scadenti e non verificabili possono essere discussi!

Answer 5

Totalmente d'accordo con la risposta di Ian Nelson.Inoltre, inizierei a mettere in atto alcuni test di "alto livello" (test funzionali o dei componenti) per preservare il comportamento dal punto di vista dell'utente.Questo punto potrebbe essere la preoccupazione più importante per il tuo PM.