[Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

Giovanni Porcari giovanni.porcari a softwell.it
Gio 10 Mar 2016 15:21:23 CET


> Il giorno 10 mar 2016, alle ore 14:58, enrico franchi <enrico.franchi a gmail.com> ha scritto:
> 
> 
> 
> 2016-03-10 1:34 GMT+00:00 Marco Beri <marcoberi a gmail.com>:
> 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, e' una posizione complicata e rischiosa. Cioe', oggettivamente, siamo tutti adulti (chi piu' chi meno) e si puo' ammettere che effettivamente ci sono bachi che fai fatica a scovare con i test. Possiamo anche dire che meno il codice e' testabile e piu' e' facile che suddetti bachi esistano. 
> 
> Pero' mettere "in avanti" questa affermazione porta problemi. E' *diverso* avere il baco, vedere il servizio crollare come un castello di carte, fare root cause analysis, trovare di conseguenza il problema e a quel punto, quando ci si va a chiedere cosa si sarebbe potuto fare per evitarlo (ovvero cosa si fara' perche' non si ripresenti) constatare che si, quel baco era talmente complicato da scovare con i test che di fatto "non si sarebbe potuto fare di meglio" e che l'unica cosa che si puo' fare e' mettere a sto punto dei regression test. A me verrebbe pure da aggiungere che bisognerebbe riflettere sul perche' quel codice contiene bachi insidiosi che non acchiappi con i test (nota, non sto parlando di genro, sono in astratto).
> 
> Ma mettere *a priori* l'affermazione "comunque i bachi piu' insidiosi non li scopri con i test" e' un po' un blanket statement che si legge come: i test non servono davvero troppo, quindi inutile spendere il costo di scriverli.
>   
> Non è che i test ti fanno scoprire i bachi.
> 
> Si, i test ti fanno anche scoprire i bachi. Fare test come si deve *prima* di andare in produzione tipicamente acchiappa un mucchio di bachi. Fare integration testing ne acchiappa altri. Ehi... perfino fare load testing acchiappa "bachi" (ok, tecnicamente non sono bachi, ma sono sempre cose che fanno svegliare la notte e fanno incazzare gli utenti.
>  
> I test ti garantiscono le non regressioni (e già questo li rende irrinunciabili).
> 
> +1
>  
> 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).
> 
> +1
>  
> Così è più faticoso che fixare subito il baco? Certo. Ma a tendere è più conveniente? Più certo ancora.
> 
> Anche perche' se no che faccio... prendo il codice che *credo* fixi il baco e lo metto in produzione? E poi scopro che non fixa un accidenti? O che magari non ho capito il baco? E che magari il fix in realta' oltre fixare un baco introduce un problema? No TY.
> 
>  
> Dici che c'è del  codice non si può testare?
> Chiedi a Valentino, lui ti direbbe che non esiste codice siffatto :-)
> 
> No no... esiste: si chiama codice scritto ammerda. E' una proprieta' assolutamente cross-platform e cross-linguaggio.
> Aggiungo... secondo me c'e' piu' codice scritto ammerda che codice scritto ammodo. 
>  
> C'è chi sostiene che un bug è in realtà un test non scritto.
> 
> Non troppo lontana dalla realta'. 
> 


Si. Tutto vero.  Tutto sacrosanto. Tutto giusto.

Però come dicevo in un'altra mail è un problema di risorse che puoi avere e non avere
e le compatibilità economiche non sono meno importanti di quelle tecniche.
Non posso parlare per altri ma solo per me. Lavoro in questo ambito da più di 40 anni
e non ho mai infilato in produzione dei bachi che non fossero 'cosmetici'. 

Che poi questo dipenda da fortuna, capacità, senso di responsabilità o attenzione non lo so.

Forse il rovescio della medaglia è che se ti convinci che i test comunque ti parano il culo
tendi a lavorare con il medesimo.
Un po' come l'acrobata che cammina sul filo senza la rete sotto: o sta attento o è un uomo morto.

Io non dico che avere un'ottima copertura dei test sia sbagliato anzi, è una cosa meravigliosa.
Dico solo che io, purtroppo, non me la posso permettere :)

Se questo significa lavorare ammerda pazienza. Per ora con questa 'ammerda' ho mangiato e 
non ho mai messo in difficoltà i miei clienti :)


Buona giornata :)

G




Maggiori informazioni sulla lista Python