I progetti costruiti con TDD oppure pensati per il "design for testabiliy" sono creati e pensati per essere "testati" con facilità, purtroppo così non è per i sistemi legacy. Quando si mette mano ad un sistema preesistente per rifattorizzarlo è di primaria necessità costuire una batteria di test i più dettagliati possibile, ma spesso si incontrano difficoltà. Un caso tipico è una funzione di questo tipo:
In questo caso il SUT (System Under Test) esegue codice in base ad un settaggio che è memorizzato su un database. Questa tipologia di codice è molto comune e rende difficile effettuare il test, soprattutto perché dal test si deve essere in grado di esercitare entrambi i percorsi della funzione da verificare. La prima soluzione è quella di utilizzare un Database Sandbox
che permetta di eseguire i vari test fornendo al SUT i valori desiderati per il parametro mysetting. Il problema in esame deriva da un problema più generale che è rappresentato nella figura seguente.
Il DOC rappresenta il Depend On Component ovvero un componente da cui il SUT dipende, nel nostro caso è il database che fornisce un indirect input ovvero un valore di input indiretto al SUT. Come detto precedentemente un database sandbox risolve il problema, si crea infatti un istanza di database per ogni tester e la si precarica prima di ogni test con il valore desiderato in modo da creare la test fixture desiderata. Questa soluzione porta con se però alcune spiacevoli conseguenze, tra cui il test smell Slow Test, sempre presente quando ci si interfaccia direttamente con un database. Questa soluzione permette di impostare gli input indiretti del SUT agendo direttamente sul DOC.
Una soluzione alternativa che presenta il minimo impatto sul sistema legacy viene dal Test Specific Subclass, che probabilmente costituisce la soluzione a meno impatto per il SUT. La prima cosa da fare è cambiare la signature della funzione ReadSettingFromDatabase() in modo che sia non più statica privata, ma virtuale e protetta, fatto questo si crea una classe che eredita dal SUT e si fa l'override della funzione ReadSettingFromDatabase().
Cosi facendo è possibile utilizzare la classe TestExampleSUT nei propri test e grazie al fatto che la funzione ReadSettingFromDatabase() è virtuale, si può forzare un valore di ritorno dal proprio test rendendo quindi banale esercitare entrambi i percorsi del metodo DoSomething. Il test cosi costruito è inoltre più veloce perché il SUT non ha bisogno di accedere ad un vero database, ma il vantaggio più grande di questa tecnica è che il SUT non ha più dipendenze dal DOC e questo è stato fatto senza cambiare l'interfaccia pubblica del SUT ed intervenendo in maniera minima su di esso. Il codice in produzione continua ad accedere al database per recuperare il valore del settaggio, mentre il codice di test è auto consistente e non ha più input indiretti.
La tecnica del Test Specific Subclass
permette quindi di aumentare la Testabilità del codice legacy intervenendo in maniera minimale sul SUT.
Alk.