Vediamo come sfruttare Infrastructure as Code per il provisioning e il testing in un ambiente di integrazione Per un nostro cliente stiamo svolgendo delle attività di svecchiamento su alcuni prodotti, migrando gradualmente verso architetture a microservizi. Uno dei prodotti in questione ha seguito per molto tempo la politica del “non toccare ciò che funziona”, con il risultato di diventare ingestibile con il passare del tempo. Alcune classi che rappresentano la logica business sono cresciute a dismisura, diventando molto complesse da modificare, con una copertura dei test insufficiente e con una logica di business condivisa tra i vari domini che convivono nella stessa codebase.…

Vediamo insieme perché un coverage del 100% non basta a farci dormire tranquilli Nel mio precedente articolo, abbiamo visto come testare e rifattorizzare un progetto legacy utilizzando il Golden Master Pattern. Stavolta, continueremo a parlare di testing, introducendo un nuovo paradigma attraverso un semplice esempio. Siamo abituati a scrivere test basandoli su esempi. In letteratura si parla di “Example test“: dato un input abbiamo un output atteso. La diffusione di tecniche come il TDD e la crescente importanza assunta in generale dai test nella realizzazione di un prodotto software rischiano di creare un grosso fraintendimento, ossia che una buona suite di test è tale se massimizza la coverage.…

Let’s see together how to modify legacy code ensuring it works thanks to the Golden Master Pattern Chiunque lavori nel mondo dello sviluppo software avrà avuto l’esigenza di aggiungere feature al codice legacy, ereditato magari dal precedente team e su cui fare una fix urgentissima. Tra le tante definizioni di codice legacy che si trovano in letteratura, quella che preferisco è: “per** Legacy code** si intende il codice utile che ho paura di modificare”.…