Piccola storia.

La mattinata si presentava foriera di novità e cose nuove: la sera precedente avevo letto per la prima volta degli unit test, e incredibilmente avevo capito subito il meccanismo di funzionamento e le regole base per utilizzare lo strumento in modo efficace.

Ero intenzionato ad applicare quanto appreso nel team di cui facevo parte, così da rendere il software in sviluppo più testato e più stabile.

Con questi pensieri in testa avevo varcato il portone per andare in ufficio e, senza nemmeno prendere il caffè, mi ero precipitato alla scrivania per scrivere il mio primo unit test.

Avrei così fatto vedere al mondo intero e a miei colleghi come si usava lo strumento. Già sognavo l’approvazione del capo, nonché grandi apprezzamenti dei colleghi e magari, in mezzo a tutto quel clima di approvazione che avrei potuto creare, anche il numero di telefono di quello splendido pezzo di receptionista appena assunta (qualcosa tipo la foto a fianco) per poterla invitare fuori (erano anni in cui, per approcciare una ragazza, non si usavano i social....... ma si chiedeva il numero di cellulare).

Dopo aver iniziato a scrivere il primo test con la prima classe (tra l’altro la più semplice in fatto di algoritmo), mi rendo conto subito che le cose non sono così semplici come avevo immaginato.

Infatti la classe sotto attacco presentava svariate dipendenze con classi esterne, che rendevano semplicemente impossibile scrivere degli unit-test in modo lineare e semplice come invece mi ero immaginato.

Dopo una giornata di parolacce e preghiere (anche alternate consecutivamente) mi sono reso conto che gli unit-test vanno di pari passo con le classi fake, e/o un framework di mocking, come Moq (che, per inciso, all’epoca del racconto Moq ancora non esisteva, anzi forse il suo autore forse nemmeno era nato).

Questa necessità nella lettura serale non l’avevo compresa, sicuramente preso dall’entusiasmo.

Quanto sopra, con buona approssimazione, è la cronistoria di quando ho tentato la prima volta di usare gli unit-test, senza averne approfondito tutti gli aspetti.

Per terminare la storia la famosa settimana si è conclusa con me che riprendo ho ripreso in mano i “sacri testi” e studio con precisione anche le pagine dedicate alle fake-class.

Per la cronaca alla fine sono riuscito nell’intento, ma mi ci sono volute ancora diverse settimane di studio e refactoring del codice esistente e, manco a dirlo, la bella receptionista nel frattempo si era fidanzata con un mio collega, che non aveva perso tempo poiché la sera invece di studiare gli unit-test l’aveva invitata fuori.

La morale è semplice: se avete qualche bella ragazza (o ragazzo) da invitare fuori, state lontani dagli unit test.

Nello scorso post ho fatto un mare di chiacchere, ma non sono ancora arrivato al succo di come si creano praticamente gli unit-test.

Mi è sembrato corretto dare prima degli elementi di contesto per meglio comprenderne fini e utilizzi.

Poi tutto sommato a pensarci bene il blog è mio, per cui per quale motivo mi devo giustificare ??

Quindi dicevo: gli unit-test sono una metodologia che permette di programmare dei test in modo automatico.

L’idea è quella di isolare dal contesto gli elementi principali del software e programmare dei test continui per assicurarne il corretto funzionamento.

Tutto questo suona bene, ma… non è tutto oro quello che luccica. Infatti implementare gli unit-test è indubbiamente faticoso, e introduce anche la necessità di conoscere tutta una serie di strumenti che servono semplicemente a favorire i test, e a null’altro.

In questa piccola serie proporrò due di questi strumenti che ritengo indispensabili: xUnit e Moq.

Da anni mi occupo di software gestionale: in questo ambito la correttezza dell’algoritmo implementato rappresenta la parte più importante del software prodotto.

Quello che voglio dire è che in questo campo specifico elementi come perfomance, bellezza delle UI e architettura impiegata rappresentano fattori assolutamente secondari e trascurabili rispetto alla correttezza e precisione dei risultati prodotti.

Una maschera che permette inserire dei dati contabili può essere bella e funzionale quanto si vuole, nonché essere velocissima e appoggiarsi sull'architettura più estensibile e moderna possibile, ma se capita che in un aggiornamento porti alla situazione in cui un qualsivoglia conteggio previsto dalla faragginosa contabilità italiana risulti essere errato, o anche solo non correttamente arrotondato, allora l’intero software viene considerato una emerita schifezza.

Per questo motivo la gestione dei test del software gestionale prodotto è una procedura che deve sempre essere eseguita con "religiosa" cura: uno sbaglio, seppur minimo, dei calcoli eseguiti è considerato alla stregua di un tradimento.

Nella pratica per realizzare test per tale tipo di software ci si è sempre basati su un approccio misto: parte dei test vengono eseguiti in modo automatico, tramite unit-test, e parte in modo manuale, con l’utilizzo di personale addestrato a trovare, calcolatrice alla mano, i seppur minimi difetti dei calcoli proposti.

Xamarin vers. 3.5 ha portato un’interessante novità: il Bindable Layout.

Devo ammettere che la prima volta che ne ho letto non mi ha convinto per nulla: mi sembrava la classica "soluzione in cerca di un problema".

Però poi mi sono sforzato di trafficarci per vedere se mi poteva essere utile e mi sono reso conto che, come spesso capita, non ne avevo capito una cippa: in effetti questa nuova feature è in grado di fornire un valido strumento per poter risolvere velocemente un bel po' di rogne.

Per questo motivo mi sono deciso a scriverne qualcosa, in modo tale da fissare le mie idee sull'argomento.

Che cappero è il Bindable Layout ?

Penso che tutti Voi conosciate la classi Layout e le sue derivate: queste rappresentano le classi container delegate a contenere e posizionare in modo automatico e nel modo corretto i controlli figli.

Alcuni esempi notevoli: Absolute Layout, Stack Layout, Grid.