> Il giorno 10 mar 2016, alle ore 14:58, enrico franchi > <enrico.fran...@gmail.com> ha scritto: > > > > 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'. >
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 _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
