[Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Giovanni Porcari]

> Il giorno 10 mar 2016, alle ore 02:34, Marco Beri <marcoberi a gmail.com> ha scritto:
> 
> 2016-03-09 23:53 GMT+01:00 Giovanni Porcari <giovanni.porcari a softwell.it>:
> Comunque i bachi più insidiosi, purtroppo non li scovi con i test.
> 
> Giovanni,
> credo sia "the other way around".
> 
> Non è che i test ti fanno scoprire i bachi.
> 
> I test ti garantiscono le non regressioni (e già questo li rende irrinunciabili).
> 
> Poi, quando scovi un baco, la prima cosa da fare è scrivere un test che lo evidenzi. Solo dopo lo correggi (e te ne accorgi quando passa il test che lo evidenziava).
> 
> Così è più faticoso che fixare subito il baco? Certo. Ma a tendere è più conveniente? Più certo ancora. Dici che c'è del  codice non si può testare? Chiedi a Valentino, lui ti direbbe che non esiste codice siffatto :-)
> 
> C'è chi sostiene che un bug è in realtà un test non scritto.
> 

Marco non pensare che non sia convinto della necessità di avere dei buoni test
in modo da non essere mai a rischio di regressioni.

Sono certissimo che sia ottima cosa.

Come sono certo, ma davvero certo, che un'ottima documentazione sia la chiave di volta
per avere un prodotto condivisibile con altri sviluppatori.

Come sono certo del fatto che dovrei finalmente rompere gli indugi e passare a python 3.

Purtroppo, da imprenditori, e io sono un piccolissimo imprenditore, sappiamo che ci sono
costi che ti puoi permettere e costi che non ti puoi permettere. Magari vivessi in un
altro paese troverei fantomatici finanziatori in grado di assicurarmi le risorse per
fare tutto senza dovere ipotecare la casa dove vivo.

Quindi devo fare delle scelte, che, per carità, possono essere alla lunga anche
scelte sbagliate. Ma gli aspetti economici di un progetto sono comunque importanti.

In Softwell siamo in tutto 5 sviluppatori e abbiamo scritto tutto Genropy e una serie
di applicativi che vanno dalla gestione dei trasporti, alla gestione dei contratti 
editoriali, poliambulatori, condomini, gestione di produzione e da ultimo Erpy,
che è un ERP che sta venendo proprio benino.

Tra tutte queste cose l'attività che ci è costata di più è stata di volta in volta
la migrazione dei dati da sistemi legacy che andavamo a sostituire. Gestire degli interregni
in cui il sistema legacy e quello nuovo coesistono e devono essere tenuti sincronizzati
è un piccolo grande incubo.

Poi un altro aspetto che è davvero oneroso è stare dietro alle fantastiche trovate
dei nostri governanti. Realizzare in 2 settimane uno 'spesometro' che deve riclassificare
 'ad minchiam' dati caricati nell'anno precedente e trasmetterli a chi di dovere
con un formato demenziale è qualcosa che solo chi lo ha fatto può capire quanta fatica costi.

Ora purtroppo in questa attività 'concreta' e fatta di costi da tenere d'occhio, 
clienti da tenere buoni e opportunità da non perdere, il tempo è quello che è.

La ricerca di bachi è, per fortuna nostra, un qualcosa di poco impegnativo o perchè
siamo molto ma molto fortunati o magari perchè la struttura di Genropy, il
modo in cui è stato ideato e scritto, rende i bachi un evento abbastanza inconsueto.

Ti racconto l'ultimo baco che abbiamo dovuto scovare. Un certo giorno di circa un mese
fa, Google ha improvvisamente aggiornato Chrome introducendo un comportamento
misterioso che rompeva il reload delle nostre pagine.

Ovvio che un baco così significa che tutti i clienti ti chiamano più o meno
contemporaneamente (il fatto che Google ti aggiorni in modo automatico
è una delle cose che detesto di più) e quindi dovevamo trovare il baco
e risolverlo nel giro di minuti.

Dopo circa mezz'ora di imprecazioni e lavoro, il fix è stato fatto e consisteva nel
rimpiazzare nel NOSTRO metodo 'reloadPage' l'istruzione:

  window.location.reload();

con:

  window.location.assign(window.location.href);

Questo mi dice 2 cose: la prima è che se nemmeno il sistema di test di Google
gli fa trovare bachi di questo genere prima di aggiornare centinaia di milioni
di browser per il mondo, allora i sistemi di test sono comunque fallaci.

La seconda cosa, assai più importante, è che wrappare in metodi TUOI
il codice secondo la funzione svolta è estremamente importante.

Avrei potuto avere in giro centinaia di chiamate a "window.location.reload();"
magari in n repository e cambiare tutto ovunque sarebbe stato molto dispendioso.

Il fatto di usare il nostro metodo 'pageReload' invece dell'istruzione base
ci ha consentito di fare un unico fix nel framework, pusharlo e fare un pull
in tutti i sistemi dei clienti. 

Quindi in meno di un ora il baco è stato sistemato.

Se avessi dovuto procedere secondo la metodologia canonica, avrei dovuto scrivere un
test in javascript che facesse un reload di pagina e verificasse questa tipologia
di errore. Forse sarei ancora qui a grattarmi la testa per capire come fare :D

Quindi, riepilogando: 

1) Concordo sul fatto che un buon sistema di test è ottima
   cosa e andrebbe speso tutto il tempo e le risorse necessarie per averlo in piedi.

2) Nel passaggio a python 3 (che spero di affrontare in autunno) mi propongo
   di partire proprio dalla revisione dei test e passare poi alla conversione vera
   e propria. Un passaggio di questo tipo senza test è semplicemente impossibile.

3) Abbiamo una piccola pattuglia di sviluppatori che hanno imparato ad usare Genropy 
   e che spero ci potranno aiutare anche nel preparare i test. Il fatto che in questa
   pattuglia manchino persone del tuo calibro e della tua esperienza è purtroppo
   qualcosa che mi spiace tantissimo ma, come sai, non dispero di averti a bordo prima o poi :P


Con questo chiudo il mio sproloquio e auguro a tutti una splendida giornata :)


G