Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

2016-03-09 Per discussione Giovanni Porcari 

> Il giorno 10 mar 2016, alle ore 02:34, Marco Beri  ha 
> scritto:
> 
> 2016-03-09 23:53 GMT+01:00 Giovanni Porcari :
> 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

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

2016-03-09 Per discussione Marco Beri 
2016-03-09 23:53 GMT+01:00 Giovanni Porcari :

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

Ciao.
Marco.

-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
http://beri.it/articoli/ - Qualche articolo
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

2016-03-09 Per discussione Marco Beri 
2016-03-09 17:19 GMT+01:00 Nicola Larosa :

> Non sarebbe bello poterli indirizzare sulle porzioni più interessanti
> dello spazio dei dati, e intanto assicurarsi di esplorare certi valori
> dimostratisi critici? È quello che fa il property-based testing, tra i
> cui esponenti ci sono QuickCheck (Haskell) del 1999 e ScalaCheck del
> 2007.
>

Avevo visto questo talk di Giorgio Sironi all'agile day:
https://vimeo.com/album/3674400/video/147027434

Si tratta della stessa cosa, immagino. Giusto?

C'è un gran bello strumento anche per Python: Hypothesis. Il suo
> funzionamento è schematizzato in questa slide:
>
> <
> https://speakerdeck.com/michelslm/property-based-testing-in-python-with-hypothesis?slide=11
> >
>
> e l'ottima documentazione contiene un bel pezzo di advocacy:
>
> 
>
> Adesso non avete più scuse: andate e testate!
>

:-))

Ciao.
Marco.

-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
http://beri.it/articoli/ - Qualche articolo
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

2016-03-09 Per discussione Giovanni Porcari 

> Il giorno 09 mar 2016, alle ore 23:40, Giovanni Porcari 
>  ha scritto:
> 
> 
>> Il giorno 09 mar 2016, alle ore 17:19, Nicola Larosa  ha 
>> scritto:
>> 
>> (I'm looking at you, Genropy. ;-) )
> 
> 
> ehm… :D
> 
> G

O per parafrasare Microsoft: 'Che serve testare se ci sono gli utenti che 
pagano per farlo ? '


Comunque i bachi più insidiosi, purtroppo non li scovi con i test.
Almeno in sistemi con delle GUI molto complesse e dove il timing 
degli eventi può essere l'elemento critico.
A volte per riprodurre un baco bisogna magari cliccare su un bottone
poi cliccare su un altro e scrollare una griglia avanti e indietro.

Capisci che studiare casi di test per cose simili è quasi impossibile.

In ogni caso bel prodotto :)

Ciao

G


___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

2016-03-09 Per discussione Giovanni Porcari 

> Il giorno 09 mar 2016, alle ore 17:19, Nicola Larosa  ha 
> scritto:
> 
> (I'm looking at you, Genropy. ;-) )


ehm… :D

G
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

2016-03-09 Per discussione Federico Fissore 

Potresti dare un'occhiata al mutation testing.

In breve: il codice sotto test viene modificato in N modi, es
if a == b
diventa
if a != b

Se il tuo test si spacca, hai una buona coverage, se il "mutante 
sopravvive", il codice è mal testato


Però non ho esperienza con python, non saprei dirti se c'è una lib e 
qual è la migliore


ciao

fede

Nicola Larosa ha scritto il 09/03/2016 alle 17:19:

Do I have your multilingual attention now? Good. ;-)

Sappiamo tutti che, se da un lato il codice *testato* non garantisce il
corretto funzionamento, dall'altro il codice *non testato* garantisce il
malfunzionamento al 99.99%.

Purtroppo scrivere unit test con un coverage decente è costoso (con
"decente" > 95%): bisogna scrivere molti test, e vanno tenuti
aggiornati mentre il codice evolve.

Ma dato che i test automatizzano l'esecuzione del codice, non sarebbe
bello automatizzare anche la generazione dei test?

È quello che fanno gli strumenti di fuzzy testing: voi scrivete un test
che invoca un pezzo di codice, e loro lo invocano a ripetizione
esplorando casualmente lo spazio dei dati in ingresso.

Sono strumenti efficaci nel trovare bug inaspettati, ed hanno un costo
di utilizzo basso; hanno però il difetto di "sparare nel mucchio",
rischiando di spendere molto tempo su dati poco rilevanti, e al
contempo mancare valori critici.

Non sarebbe bello poterli indirizzare sulle porzioni più interessanti
dello spazio dei dati, e intanto assicurarsi di esplorare certi valori
dimostratisi critici? È quello che fa il property-based testing, tra i
cui esponenti ci sono QuickCheck (Haskell) del 1999 e ScalaCheck del
2007.

C'è un gran bello strumento anche per Python: Hypothesis. Il suo
funzionamento è schematizzato in questa slide:



e l'ottima documentazione contiene un bel pezzo di advocacy:



Adesso non avete più scuse: andate e testate!


(I'm looking at you, Genropy. ;-) )



___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

2016-03-09 Per discussione Nicola Larosa 
Do I have your multilingual attention now? Good. ;-)

Sappiamo tutti che, se da un lato il codice *testato* non garantisce il
corretto funzionamento, dall'altro il codice *non testato* garantisce il
malfunzionamento al 99.99%.

Purtroppo scrivere unit test con un coverage decente è costoso (con
"decente" > 95%): bisogna scrivere molti test, e vanno tenuti
aggiornati mentre il codice evolve.

Ma dato che i test automatizzano l'esecuzione del codice, non sarebbe
bello automatizzare anche la generazione dei test?

È quello che fanno gli strumenti di fuzzy testing: voi scrivete un test
che invoca un pezzo di codice, e loro lo invocano a ripetizione
esplorando casualmente lo spazio dei dati in ingresso.

Sono strumenti efficaci nel trovare bug inaspettati, ed hanno un costo
di utilizzo basso; hanno però il difetto di "sparare nel mucchio",
rischiando di spendere molto tempo su dati poco rilevanti, e al
contempo mancare valori critici.

Non sarebbe bello poterli indirizzare sulle porzioni più interessanti
dello spazio dei dati, e intanto assicurarsi di esplorare certi valori
dimostratisi critici? È quello che fa il property-based testing, tra i
cui esponenti ci sono QuickCheck (Haskell) del 1999 e ScalaCheck del
2007.

C'è un gran bello strumento anche per Python: Hypothesis. Il suo
funzionamento è schematizzato in questa slide:



e l'ottima documentazione contiene un bel pezzo di advocacy:



Adesso non avete più scuse: andate e testate!


(I'm looking at you, Genropy. ;-) )

-- 
Nicola 'tekNico' Larosa 
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python