Lavoro su un prodotto abbastanza grande. E 'stato in fase di sviluppo da. Net 1.0 era ancora un work-in-progress e quindi ha un sacco di codice di cattiva qualità e non è stato scritto con test unitari in mente. Ora stiamo cercando di migliorare la qualità e implementare i test per ogni funzionalità e correzione degli errori. Uno dei più grandi problemi che stiamo avendo ora è l'inferno della dipendenza e gli oggetti divini. C'è un oggetto dio in particolare che è cattivo: Session. Fondamentalmente, tutto ciò che riguarda la sessione corrente del programma è in questo oggetto. Ci sono anche alcuni altri oggetti di dio.L'ereditarietà dell'interfaccia per suddividere gli oggetti divini?
In ogni caso, abbiamo reso questo oggetto divino "mockable" utilizzando Resharper per estrarre un'interfaccia da essi. Tuttavia, questo rende ancora difficile testare perché la maggior parte delle volte è necessario guardare il codice che si scrive per capire cosa realmente ha bisogno di essere deriso dai 100 diversi metodi e caratteristiche.
Proprio la suddivisione di questa classe è fuori questione in questo momento perché ci sono letteralmente centinaia se non migliaia di riferimenti a questa classe.
Perché ho un'interfaccia (e quasi tutto il codice è stato refactored per utilizzare l'interfaccia), tuttavia, ho avuto un'idea interessante. Cosa succede se ho fatto ereditare l'interfaccia ISession da altre interfacce.
Per esempio, se avessimo qualcosa di simile:
interface IBar
{
string Baz{get;set;}
}
interface IFoo
{
string Biz{get;set;}
}
interface ISession: IFoo, IBar
{
}
In questo modo, il codice esistente utilizzando ISession non avrebbe dovuto essere aggiornato, né l'effettiva implementazione deve essere aggiornato. Ma, nel nuovo codice che scriviamo e refactor possiamo usare le interfacce IFoo o IBar più granulari, ma passiamo a un'ISession.
E alla fine, vedo questo come probabilmente rendendo più facile per rompere finalmente il reale ISession e Dio Sessione interfaccia/oggetto
Ora a voi. È un buon modo per testare questi oggetti divini e alla fine distruggerli? Si tratta di un approccio documentato e/o di un modello di progettazione? Hai mai fatto qualcosa del genere?
+1: Sembra un modo ragionevole per eseguire un refactoring passo-passo. –
Se non lo si è verificato, [Lavorare efficacemente con il codice legacy] (http://amzn.com/B005OYHF0A) di Michael Feathers può rivelarsi prezioso. Contiene molte strategie per aiutarti a mettere in discussione un progetto come questo. Molti di loro sono ovvi, ma vederli in stampa ti aiuta a farti passare e farlo. –
@AnthonyPegram che è in realtà il prossimo libro sulla mia lista per ottenere – Earlz