2016-03-10 1:34 GMT+00:00 Marco Beri <marcob...@gmail.com>: > 2016-03-09 23:53 GMT+01:00 Giovanni Porcari <giovanni.porc...@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-
_______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
