Il problema chiave con il codice legacy è che non ha test. Quindi è necessario aggiungere alcuni (e poi altro ...).
Questo di per sé richiederebbe molto lavoro, come ha notato @mattnz. Ma il problema speciale del codice legacy è che non è mai stato progettato per essere testabile . Quindi in genere è un enorme casino contorto di codice spaghetti, in cui è molto difficile o assolutamente impossibile isolare piccole parti da testare. Quindi, prima del test unitario, è necessario riformattare il codice per renderlo più testabile.
Tuttavia, al fine di effettuare il refactoring in modo sicuro, è necessario disporre di test unitari per verificare di non aver rotto nulla con le modifiche ... Questa è la cattura 22 del codice legacy.
Il libro ti insegna come uscire da questo problema apportando le modifiche minime e più sicure al codice solo per abilitare i test della prima unità. Questi non hanno lo scopo di rendere il design più gradevole, ma solo di abilitare i test unitari. In effetti, a volte rendono il design più brutto o più complesso. Tuttavia, ti consentono di scrivere test e, una volta che hai messo in atto i test unitari, sei libero di migliorare il design.
Ci sono molti trucchi per rendere testabile il codice - alcuni sono in qualche modo ovvi, altri no. Ci sono metodi che non avrei mai pensato a me stesso, senza leggere il libro. Ma ciò che è ancora più importante è che Feathers spiega cosa rende precisamente testabile un'unità di codice. Devi tagliare le dipendenze e introdurre barriere nel tuo codice, ma per due motivi distinti:
- rilevamento - al fine di verificare e verificare gli effetti dell'esecuzione di un pezzo di codice, e
- separazione - al fine di ottenere innanzitutto il pezzo di codice specifico in un cablaggio di prova.
Tagliare le dipendenze in modo sicuro può essere complicato. L'introduzione di interfacce, simulazioni e dipendenza dall'iniezione è pulita e piacevole come obiettivo, ma non è necessariamente sicuro da fare a questo punto. Quindi a volte dobbiamo ricorrere alla sottoclasse della classe sotto test al fine di sovrascrivere un metodo che normalmente ad esempio avvia una richiesta diretta a un DB. Altre volte, potremmo anche aver bisogno di sostituire una classe di dipendenza / jar con una falsa nell'ambiente di test ...
Per me, il concetto più importante introdotto da Feathers è la cucitura . Una cucitura è un punto nel codice in cui puoi cambiare il comportamento del tuo programma senza modificare il codice stesso . La creazione di giunzioni nel codice consente di separare il pezzo di codice in prova, ma consente anche di rilevare il comportamento del codice in prova anche quando è difficile o impossibile eseguire direttamente (ad esempio perché la chiamata apporta modifiche in un altro oggetto o sottosistema , il cui stato non è possibile eseguire una query direttamente dall'interno del metodo di test).
Questa conoscenza ti consente di notare i semi della testabilità nel mucchio di codice più cattivo e di trovare le modifiche minime, meno dirompenti e più sicure per arrivarci. In altre parole, per evitare di rendere "ovvi" i refactoring che rischiano di infrangere il codice senza che te ne accorga, perché non hai ancora i test unitari per rilevarlo.