[Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[enrico franchi]

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'.


-- 
.
..: -enrico-
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20160310/5ae5b9f1/attachment.html>