Stamattina mi sono trovato di fronte ad una situazione che ultimamente affronto un po' troppo spesso, impiegando circa un'ora di letture fra blog e articoli. In particolare ho voluto affrontare (per l'ennesima volta) una questione "teorica" riguardo lo unit testing: l'utilizzo di un framework di mock.
Non voglio in questa sede dilungarmi sul fatto che esistano diversi tipi di oggetti simulati secondo la tradizionale definizione di Fowler (dummy, fake, stub, mock), bensì esprimere tutto il mio personale rammarico circa alcuni mie atteggiamenti da ingegnere riguardo lo sviluppo software.
In pratica mi sto rendendo conto che la mia produttività sta scemando nel tempo perchè a rischio perfezionismo. La mia forma mentis è quella dell'ingegneria, e fino a qualche mese fa non mi rendevo conto di quanto questa sia pervasiva nella mia vita professionale. Non che sia un male intendiamoci, però credo che ci debba essere anche un limite.
Il problema che comincio a intravedere è che tendo troppo spesso a ritrovarmi insoddisfatto di fronte ad alcune soluzioni implementative che realizzo, eccedendo nel refactoring o addirittura nella sovraingegnerizzazione progettuale.
L'esempio lampante di quanto sto dicendo lo sto vivendo proprio in questo ultimo periodo, lavorando su un progetto che fa uso dell'Entity Framework. Quest'ultimo soffre di errori di progettazione abbastanza evidenti a livello architetturale per essere un ORM, il suo lavoro lo fa per carità, ma a costo di alcune magagne fra cui l'ormai famigerata Persistence Ignorance per quanto riguarda le classi che fanno parte del Domain Model.
Ebbene, ho provato per diversi giorni ad analizzare da ogni punto di vista la questione cercando in tutti i modi di trovare una soluzione elegante che facesse il paio con alcune pratiche di buona implementazione architetturale che sto cercando di raggiungere, con risultati del tutto deludenti (insomma la cosa per come è fatto l'EF è impossibile, punto).
Ma quello che a prima vista poteva essere scambiato come il cercare di combattere contro un framework nato e pensato male, battaglia se vogliamo del tutto legittima, stamattina ho capito essere altro.
Nel mondo reale le soluzioni software devono essere rilasciate nei tempi e nei costi progettati, devono aderire a precisi requisiti (funzionali e non), fine del discorso.
Impiegare per l'ennesima volta un'ora del mio tempo per derimere un dubbio stucchevole circa la differenza di utilizzo fra mock e stub in uno unit test, non va in alcun modo in questa direzione.
Non voglio essere frainteso: non sto dicendo che non sia importante capire la differenza fra testare lo stato (con uno stub) o testare il comportamento/interazione (con un mock). Sto affermando che esiste una netta differenza fra me e Martin Fowler (maddai...), esattamente come esiste la differenza fra un premio nobel per la fisica ed un ingegnere che deve progettare e costruire un ponte strallato.
Detto in termini meno metaforici, non devo perdere di vista che l'obiettivo è quello di dotare la mia soluzione software di una suite di test robusta, ma che in nessun caso debba essere causa, di una inutile ricerca della perfezione semantico-semiotica circa l'arte teoretica dello unit testing.
Questo al momento è il maggiore limite che sto notando nella mia formazione unievrsitaria, che se da una parte mi ha dato la capacità di affrontare le questioni professionali con metodo, dall'altra, non mi ha affatto insegnato la differenza che c'è fra la teoria e la pratica, e questo per colpa della natura stessa dell'università italiana, che anche ad ingegneria difetta pesantemente di pragmatismo.
In definitiva sto facedo training autogeno, per combattere l'"ansia da prestazione" circa il confronto fra ciò che sto producendo e l'empireo degli archetipi dello sviluppo software.