Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Carlos Catucci]

2016-03-18 16:14 GMT+01:00 Giovanni Porcari :

>
> Se esiste un sistema di test di questo genere e se posso implementarlo ai
> prezzi da
> fame che i clienti sono disposti a pagare vi prego di dirmelo :).


Viaggia nel tempo e procurati degli schiavi. Altri metodi per ora non mi
vengono. Ci sono dei bagali che permettono di automatizzare dei test
funzionali su GUI ma i test dovresti scriverteli e se vuoi coprire tutti i
casi possibili delle cose che l'utente potrebbe fare ...

A proposito di viaggio nel tempo, avrei giusto un annuncio economico da
mettere

A.A.A. Ieri vendero' macchina del tempo perfettamente funzionante. ;)

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[enrico franchi]

2016-03-18 10:28 GMT+00:00 Carlos Catucci :

> Tutto e' relativo, dipende dal contesto.
>

Yep.


> Io per esempio per garantire di poter lavorare anche se la ruspa dei
> lavori in corso trancia i cavi dell'adsl (ci e' successo realmente a
> Modena) un rapsino con un disco in replica che puo' fungere da macchina di
> backup locale lo propongo. Poi dipende da cosa fa il servizio/applicazione.
> Se devo solo consultare ogni tanto non da problemi, ma se ho tutto li sopra
> ecco che il sistema di backup locale diventa vitale.
>

Breaking news... da qualche mese e' disponibile una nuova cosa chiamata
"cloud computing", che vuole dire che in pratica ti scegli il modello di
ridondanza/availability che vuoi e fine della fiera. Vuoi piu' availably
zones? Puoi. Pensi che tutto sommato devi proteggerti da un evento
catastrofico, che so... in us-east-1? bene... prendi qualcosa anche in
us-east-2. Pensi che tutta l'america possa venire invasa dagli alieni (ci
sono le foto! [0]), prendi qualcosa anche che so... in Australia. I canguri
terranno lontani gli alieni. Etc etc etc. ;)

Poi le ruspe continueranno a tranciare i cavi. Pero' smette di essere un
problema tuo...


---
[0]
http://vignette3.wikia.nocookie.net/aliens/images/b/b2/Alien_Independence_Day.png/revision/latest?cb=20110124141918



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

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Carlos Catucci]

2016-03-18 15:09 GMT+01:00 enrico franchi :

>
> Breaking news... da qualche mese e' disponibile una nuova cosa chiamata
> "cloud computing", che vuole dire che in pratica ti scegli il modello di
> ridondanza/availability che vuoi e fine della fiera. Vuoi piu' availably
> zones? Puoi. Pensi che
>
[...]

> Poi le ruspe continueranno a tranciare i cavi. Pero' smette di essere un
> problema tuo...
>

Enrico se le ruspe tranciano il cavo della connessione dove sono le
postazioni di lavoro (ufficio del cliente) non esiste cloud che mi faccia
andare.

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Carlos Catucci]

2016-03-18 15:59 GMT+01:00 Giovanni Porcari :

> No. Però un bel modem 4G qualcosa di buono fa…


Concordo, se sei coperto da rete 4G. Cosa che per molte (troppe) zone in
questo paese non corrisponde al vero.

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[enrico franchi]

2016-03-18 10:58 GMT+00:00 Gollum1 :

>
>
> lasciamo perdere va... sono da mesi oramai che chiedo di replicare
> localmente un server di autenticazione, che ora è solo a Roma...
>
> in un paio di occasioni c'é stato un problema sulle linee di
> comunicazione, e ci siamo trovati con la produzione ferma, solo perché
> gli utenti (montatori) non potevano loggarsi sulle macchine di
> montaggio... (una delle due volte, si era spenta tutta la farm in cui
> risiedono i loro server di autenticazione, un disastro).
>
> ma ingegneria non ci sente... stupidi...
>
>
Unipr, l'anno scorso... storia breve, c'era un UPS vecchiotto che stava
schiattando. Dovevano fare lavori elettrici.
Fanno i lavori elettrici. L'UPS era vecchio ed e' schiattato. Doveva essere
ridondato ma non lo era.
Va giu' un po' di roba... nulla di importante, se non, precisamente, il
server di autenticazione. Bene... non ridondato. Meglio. Avevo detto storia
breve? Beh, in pratica *tutto* (email inclusa) ha smesso di funzionare per
10 giorni... fra cui l'iscrizione agli esami.


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

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[enrico franchi]

2016-03-15 18:22 GMT+00:00 Carlos Catucci :

> Questione di scala Enrico.


A me verrebbe dire anche questione di business, piuttosto. O se vuoi, del
tipo di business e del modello di deploy che hai.

Per esempio se fai sw "boxed" i rilasci sono costosissimi e vuoi certamente
dell'infrastruttura massiccia di QA. D'altra parte per la maggior parte dei
sw l'utente si aspetta che ci siano dei bachi. Insomma, Word (o chi per
lui) ogni tanto crasha. Lo sappiamo tutti e continuiamo ad usarlo (magari
usiamo il "chi per lui", che a sua volta ogni tanto va giu'). Pero' grosso
modo e' su... il motivo e' che di fatto l'infrastruttura e' interamente in
mano all'utente. Che d'altra parte vuole dire che determinati tipi di
testing diventano molto piu' complicati. Il caso "pessimo" e' quello dei
giochi che magari hanno bachi nei motori grafici che sono triggerati solo
da certe combinazioni di un certo modello di scheda video con una certa
versione dei driver su una certa versione di un certo sistema operativo.

Se c'e' un baco, si considera ok aspettare qualche mese per avere una minor
version che lo aggiusta. Inoltre, se si introduce un baco, basta dare un
buon modo all'utente di usare la vecchia versione e probabilmente gli si da
solo un fastidio marginale. Non solo... certi utenti si aspettano che la
nuova versione abbia bachi e prima di "adottarla" la testano. Pochi, eh...
ma spesso quelli per cui e' veramente critico lo fanno.

Il modello dei servizi web e' opposto. Ci si aspettano rilasci brevi. Ci si
aspetta che il software sia sempre su. I bachi sono una cosa statistica:
ovvero sappiamo che per qualche utente ci saranno dei problemi, ma fintanto
che il singolo utente non ha problemi troppo spesso si puo' tollerare. Poi
ci sono un mucchio di cose che sappiamo che andranno storte... quindi via
di retry. Che so... se faccio una chiamata ad un servizio, puo' andare male
anche solo per questioni di rete o del momento in cui succede. Ma magari il
servizio di per se e' su e non c'e' davvero un "baco" nel codice. Riprovo
tutto e vado. Magari l'utente stesso e' disposto di tanto in tanto a
ricaricare la pagina per aggiustare una situazione.

E anche qui... e' diverso fare un servizio che "vendi" ad un'azienda il cui
business ne dipende. Se "vendo" un servizio di billing per ecommerce e io
sono giu', i miei clienti non possono fatturare. Non saranno tolleranti. Se
fallisco una transazione su 100, non saranno contenti. Se a mia volta il
mio servizio e' un ecommerce, gli stessi problemi sopra descritti possono
volere dire meno vendite e meno soldi. Downtime vuole dire perdite
monetarie quantificabili immediatamente. Non solo... non posso nemmeno
facilmente testare il mio codice in produzione (ovvero, iniziare a
deployare timidamente e sperare che funzioni tutto). Viceversa se sto
facendo un servizio per condividere una bacheca di puttanate con i miei
amici, posso: 1) fallire di tanto in tanto, inoltre, siccome molti fanno
sta roba dal cellulare, potrebbero addirittura pensare che non sono io a
fallire, ma che e' la connessione che e' singhiozzante; 2) testare feature
su pochi clienti alla volta... posso anche convincerli di essere fortunati
a starmi facendo da beta tester a gratis. Un celebre servizio di
microblogging aveva problemi immensi di availability eppure si e' comunque
espanso.

Comunque a prescindere da quale situazione sia, in generale "non so chi
sono i miei clienti". Ovvero sono tanti, continuano ad entrare e,
potenzialmente, ad uscire. Mi possono abbandonare probabilmente con un
costo limitato. La mia reputazione e' una cosa globale, invece: qualche
post su twitter di persone chiave puo' crearmi grossissimi problemi. Tutti
sanno chi sono (o per lo meno, tutti quelli che sono interessati al tipo di
servizio che sto vendendo/proponendo).

Se quello che fai e' invece offrire soluzioni "individuali" per clienti, e'
un mercato ancora diverso. C'e' un rapporto piu' stretto. I tempi in
qualche modo li da il cliente (mentre se faccio servizi web i tempi li da
"il mercato" -- se siamo i secondi a rilasciare questa feature abbiamo
perso la battaglia -- oppure essere quasi interno -- rilascio questa
feature quando e' pronta, o ancora, rilascio tutte le settimane, ma includo
nel rilascio solo quello che e' pronto). E poi dipendera' di volta in volta
come vengono fatti deployment, aggiornamenti, new release; se le macchine
sono mie o del cliente, quanta gestione ho sulle macchine, etc etc etc.


Questo solo per dire che siccome i modelli di business sono davvero
diversi, non e' affatto detto che una strategia completamente accettabile
in una situazione sia completamente suicida in un'altra.


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

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Manlio Perillo]

2016-03-18 16:14 GMT+01:00 Giovanni Porcari :
> [...]
> Altrettanto ovvio (almeno per me) che ogni volta che si fanno delle modifiche 
> o delle
> aggiunte di un certo peso (non quindi il css che colora in rosso una riga se 
> il camion
> non è arrivato) l'utente dispone anche di un'istanza (sempre in claud) di test
> con i dati prelevati ogni notte dal db primario.
>
> Su quella istanza pasticcia un paio di giorni controllando tutto quello
> che è vitale che funzioni in tempo reale (e nei trasporti se tieni fermo
> un camion perchè non puoi stampare la lista di carico la gente si incazza).
>
> Se nel server di test tutto è ok si aggiorna alla stessa release il server di 
> produzione
> con la ragionevole certezza che le procedure critiche sono state testate 
> dagli utenti.
>
> Mi piacerebbe avere un sistema di test che mi segnali che se l'utente dragga
> una riga di trasporto da eseguire nel viaggio previsto per domani
> e se poi cambia idea e la toglie e la mette nel viaggio della settimana
> seguente per un altro trasportatore c'è un baco per cui a video la prima riga
> risulta ancora visibile.
>
> E via dicendo per qualsiasi tipo di evento sia generato da n utenti che 
> lavorano su
> un sistema di questo tipo allocando e deallocando risorse di trasporto.
>
> Se esiste un sistema di test di questo genere e se posso implementarlo ai 
> prezzi da
> fame che i clienti sono disposti a pagare vi prego di dirmelo :).
>

Con Selenium, dovresti essere in grado di controllare se certi
elementi (individuati tramite selettori CSS o query XPATH) sono
visibili, oltre a molto altro ancora.

> [...]

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

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Carlos Catucci]

2016-03-18 18:07 GMT+01:00 enrico franchi :

> No. Ma se la postazione del cliente e' isolata dal mondo, e' un caso molto
> particolare che avendo una specifica applicazione hostata in locale tutto
> funzioni (senza accesso ad internet, a questo punto). Tutto funzioni vuole
> dire "la gente e' in grado di lavorare".
>

Non e' isolata di solito, ma puo' esserlo se hai problemi £temporanei" di
connettivita'. In tal caso la ridondnza locale non ti lascia a piedi e si
sincronizza quando tonra la connessione

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Carlos Catucci]

2016-03-15 19:09 GMT+01:00 enrico franchi :

> Ottimo. Mi fa piacere che per te funzioni. Vorrei solo che sia chiaro che
> non e' un caso generale che sia facilmente estensibile ad altri business in
> modo automatico. Appena cambi un pochetto le regole del business e' facile
> che non funzioni piu' tanto bene.
>

Questione di scala Enrico. Che poi sia giustissimo e sacrosanto scrivere i
test e' altro discorso. Ma per le cose che fa Giovanni i bug nascosti tra
le pieghe del codice magari sono meno nascosti.
Se hai una applicazione con tre bottoni, ciascuno fa una cosa specifica e
solo una, indipendentemente dall'ordine in cui li stai premendo, i bug sono
facile da beccare con il solo test funzionale di premere tutti e tre e
vedere che ciascuno faccia solo quello che deve fare. Se sempre stesso caso
ma a seconda dell'odine di pressione accade qualcosa di differente (premi
tutti e tre in un dato ordine succede una cosa, li premi in un altro
cuccede un'altar cosa) gia' piu' difficile beccare il bug con il test
funzionale. Se poi i bottonoi sono 30 o 300 ...

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[enrico franchi]

2016-03-10 14:21 GMT+00:00 Giovanni Porcari :

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

Si, appunto. Per determinati business (che so, se fai servizi web based) il
costo di un baco in produzione sufficientemente grave puo' anche nella
peggiore delle ipotesi farti chiudere baracca. Se i clienti perdono fiducia
nel tuo business, semplicemente non hai piu' clienti (per lo meno, nel
lungo termine). Se il business fa billing sulla base delle transazioni dei
clienti, downtime vuole dire potenzialmente milioni di dollari di mancate
entrate. In ogni caso probabilmente hai delle SLA che devi rispettare, e se
non le rispetti devi sbatterti non poco per scusarti (e generalmente tutto
questo coinvolge ancora una volta mancate entrate)

Certo, se vendi software "boxed" sei in un mondo completamente diverso.
Come e' diverso se vendi soluzioni custom per clienti singoli, e magari ti
va anche bene. Eh, scusa, eravamo giu' per un paio di ore, ma dai, non ti
preoccupare. In altri casi questo e' un pochetto piu' complicato.

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

Eh... che dire. Bravi. La mia esperienza, sebbene molto piu' breve, e'
tutta diversa.

Diciamo cosi'... l'esperienza (breve finche' vuoi) mi insegna a diffidare
molto di questo tipo di affermazioni.

Nel mio mondo, la parola chiave e' "build to fail". I sistemi falliranno.
Il trucco e' essere sufficientemente ridondanti. E il costo ingegnere di
scrivere un test e' assolutamente *nullo* rispetto al costo di tenere in
piedi la baracca (che a sua volta e' completamente trascurabile rispetto al
costo di fallire davvero).

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

La fortuna non perdura in eterno, il senso di responsabilita' non aiuta
(ovvero, l'incoscienza chiaramente rema contro, ma non direi che e' un
problema di "senso di responsabilita'"). Attenzione? Forse. Ma vuole anche
dire che il business ha tempi molto lenti (o se vuoi "umani"). Ma
soprattutto, non e' una garanzia. Perche' sei attento fino alla volta in
cui sei disattento.

Se vai a vedere come gestiscono le cose quelli che *non* possono
permettersi bachi *per nulla* (sarebbe piuttosto sgradevole un 404 con
l'omino dei lavori in corso sul monitor del 747 che sta precipitando con
500 persone a bordo -- sorry, we are working for you: ATC will be online in
a couple of hours, please consult your onboard spiritual advisor for your
last prayers). Beh... vedrai che non ti parlano di "attenzione" e "senso di
responsabilita'". Semmai hanno svariati team di QA che fanno test manuali,
automatici, randomizzati e pagano licenze piuttosto costose per tool che
fanno analisi statica e dimostrano l'assenza di determinati bachi in
determinate parti del codice. E a volte tutto questo si rompe e nonostante
tutto si va Arianne 5.

Ora tutto questo ha un costo immenso. Per lo meno vuole dire un ciclo di
sviluppo cosi' lungo che nel mio mondo saremmo tutti fuori dal business. E
quindi via di compromessi. Oltretutto un moderno sistema software e'
*molto* piu' complicato della maggior parte dei sistemi mission critical di
quel tipo (principalmente perche' il costo di non introdurre una feature
puo' essere molto piu' alto del costo del rischio di un downtime).

Forse il rovescio della medaglia è che se ti convinci che i test comunque
> ti parano il culo
> tendi a lavorare con il medesimo.
>

"True man do not write bugs". No. La gente scrive i test quando lavora
bene. Se non scrive i test, dal mio punto di vista, sta lavorando con il
culo. Ci sono talmente tante buone ragioni per scrivere i test... e quale
ragione per non scriverli? Risparmio tempo? In generale si dimostra che non
e' manco vero che si risparmia tempo sul lungo termine. Poi certo, se uno
se la gioca tutta sul fatto che "va in bancarotta sul debito tecnico" ok...
ma non e' un gran piano nel caso generale.

Un po' come l'acrobata che cammina sul filo senza la rete sotto: o sta
> attento o è un uomo morto.
>

Ecco... ma noi siamo acrobati che lavorano troppe ore al giorno su un filo
invisibile con illuminazione a lume di candela fatta dal pubblico
sottostante. E il filo non e' dritto ma va un po' di qua e un po' di la. E
un orso ubriaco con la faccia di Bruce Campbell ci sta inseguendo con una
motosega al posto della zampa destra.

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 :)
>

E io non conosco il tuo business, per cui non posso e non voglio commentare
oltre. I tuoi clienti sono contenti, restano, e ne continuano ad arrivare
di nuovi? Allora vuole dire che stai facendo 

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Nicola Larosa]

Giovanni Porcari wrote:
> E poi posso sempre passare a Ruby:

Fai pure se credi, ma non passare a Rails.


> http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html

Faccio fatica a leggere roba scritta da stronzi:



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

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Giovanni Porcari]

> Il giorno 10 mar 2016, alle ore 15:52, Marco Beri  ha 
> scritto:
> 
> 2016-03-10 15:43 GMT+01:00 Giovanni Porcari :
> 
> > Il giorno 10 mar 2016, alle ore 15:36, Nicola Larosa  ha 
> > scritto:
> >
> > Che è più di quanto molti di noi possano vantare, ma non puoi avere
> > culo per sempre. ;-)
> 
> Menagramo :P
> 
> 
>  
> 
> You made my day.

E poi posso sempre passare a Ruby :

http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html

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

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Marco Beri]

2016-03-10 15:43 GMT+01:00 Giovanni Porcari :

>
> > Il giorno 10 mar 2016, alle ore 15:36, Nicola Larosa 
> ha scritto:
> >
> > Che è più di quanto molti di noi possano vantare, ma non puoi avere
> > culo per sempre. ;-)
>
> Menagramo :P
>




You made my day.


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

[Giovanni Porcari]

> Il giorno 10 mar 2016, alle ore 15:36, Nicola Larosa  ha 
> scritto:
> 
> Che è più di quanto molti di noi possano vantare, ma non puoi avere
> culo per sempre. ;-)

Menagramo :P

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

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Carlos Catucci]

2016-03-10 15:36 GMT+01:00 Nicola Larosa :

> Scusa, ma è solo una tua convinzione, secondo me errata. Vedi quanto
> detto da Stefano circa il progettare il codice in funzione dei test.
>

Ecco diciamo che dipende da dove lavori. Sono stato in posti dove il test
veniva considerato uno spreco di tempo a prescindere. C'e' anche da dire
che sono andato via appena possibile.

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Nicola Larosa]

Giovanni Porcari wrote:
> Lavoro in questo ambito da più di 40 anni e non ho mai infilato in
> produzione dei bachi che non fossero 'cosmetici'.

Giovanni, scusa ma questo è altamente improbabile (soprattutto se non
avevi test :-) ). Al massimo non ti *risultano* bachi (il che è già un
successo), ma il mondo è pieno di bachi tuoi (come di tutti noi).
Aspettano solo il momento giusto per venir fuori. ;-)

 
> Forse il rovescio della medaglia è che se ti convinci che i test
> comunque ti parano il culo tendi a lavorare con il medesimo.

Questo non ha veramente senso, oltre a non aver riscontro nella realtà.


> 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 :)

Scusa, ma è solo una tua convinzione, secondo me errata. Vedi quanto
detto da Stefano circa il progettare il codice in funzione dei test.

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

Che è più di quanto molti di noi possano vantare, ma non puoi avere
culo per sempre. ;-)

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

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Stefano Bossi]

2016-03-10 15:21 GMT+01:00 Giovanni Porcari :

>
> 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 :)
>
> Secondo me l'unico modo per uscirne è lavorare in TDD e a quel punto vuol
dire fare design tramite i test.
Di conseguenza, il tempo dedicato ai test non è in più, ma è quello che
prima dedicavi alla progettazione pura.
Con il TDD riesci a scrivere codice che per forza deve essere testabile e
quindi calano i costi di mantenimento di tutta la suite.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Nicola Larosa]

Enrico Franchi wrote:
> 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.

Che è una profezia auto-avverante: se non scrivi test
*sistematicamente*, non saprai mai quanta pena t'avrebbero evitato.


> Fare test come si deve *prima* di andare in produzione tipicamente
> acchiappa un mucchio di bachi.

Intendevi fare test come si deve prima di scrivere il codice. :-)


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

Been there, done that, got the T-shirt. Never. Again. Please.


> Aggiungo... secondo me c'e' piu' codice scritto ammerda che codice
> scritto ammodo.

Questo è fuori discussione, il dubbio è su quant'è il codice scritto
come si deve. Dieci per cento? Uno per cento? Uno per mille? Meno?
Quanto meno?

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

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Giovanni Porcari]

> Il giorno 10 mar 2016, alle ore 14:58, enrico franchi 
>  ha scritto:
> 
> 
> 
> 2016-03-10 1:34 GMT+00:00 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, 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

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[enrico franchi]

2016-03-10 1:34 GMT+00:00 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, 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

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Giovanni Porcari]

> Il giorno 10 mar 2016, alle ore 11:52, Stefano Bossi  ha 
> scritto:
> 
> Anche se è molto difficile testare le GUI come anche altre forme di IO, 
> questo non vuol dire che non si possa testare tutto il resto.
> Certo, separare tutto ciò che è logica pura dall'IO è una gran fatica, 
> ma almeno sai che quella è solida e questo ha anche il vantaggio di farti 
> scrivere codice più pulito :)

Si infatti: sulla parte python 'core' e adapter_sql abbiamo dei test (anche se 
la copertura non è certo
ottimale). Ma la nostra lotta è quasi sempre sulla GUI e sul timing degli 
eventi.

Ovvero il classico baco che è anche difficile da riprodurre perchè capita 
magari ogni 2 mesi.

Sulla parte interfaccia abbiamo tutta una serie di test ma NON automatici. 
Ovvero se temo
che ci sia un baco ad esempio sulle grid, apro la mia pagina di test delle grid 
e aggiungo un sottocaso per evidenziare il problema o l'anomalia.

Quello che non riesco proprio a fare è capire come posso beccare con test 
automatici
il fatto che resizando la finestra mi compaia una scrollbar nel pannello in 
alto a sx
quando non dovrebbe. Cioè io lo vedo e dico ' cazzo ci vuole un overflow 
hidden'.
Farlo fare ad un test giuro che non saprei da che parte iniziare. Mio limite ;)


G


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

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Marco Beri]

2016-03-10 11:52 GMT+01:00 Stefano Bossi :

Anche se è molto difficile testare le GUI come anche altre forme di IO,
> questo non vuol dire che non si possa testare tutto il resto.
> Certo, separare tutto ciò che è logica pura dall'IO è una gran fatica,
> ma almeno sai che quella è solida e questo ha anche il vantaggio di farti
> scrivere codice più pulito :)
>

E, infine, in teoria ti permette di "pluggare" una nuova interfaccia senza
diventare troppo matto..

Ho imparato bene, Stefano? :-)

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!

[Stefano Bossi]

2016-03-09 23:53 GMT+01:00 Giovanni Porcari :

>
> 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.
>
> Anche se è molto difficile testare le GUI come anche altre forme di IO,
questo non vuol dire che non si possa testare tutto il resto.
Certo, separare tutto ciò che è logica pura dall'IO è una gran fatica,
ma almeno sai che quella è solida e questo ha anche il vantaggio di farti
scrivere codice più pulito :)

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

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Riccardo Magliocchetti]

Il 09/03/2016 23:53, Giovanni Porcari ha scritto:

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.


Difficile testare la ui ma non impossibile, ad esempio:
http://caolanm.blogspot.it/2015/10/fuzzing-libreoffice-input-events-with.html
http://caolanm.blogspot.it/2015/10/finding-ui-crashes-by-fuzzing-input.html

Oppure fresca di oggi e sul tema property testing:

https://twitter.com/giorgiosironi/status/707862823842533376


--
Riccardo Magliocchetti
@rmistaken

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

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[Nicola Larosa]

> Nicola Larosa wrote:
>> Non sarebbe bello poterli indirizzare sulle porzioni più
>> interessanti dello spazio dei dati, e intanto assicurarsi
>> di esplorare

Qui intendevo "controllare", tra l'altro.


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

Marco Beri wrote:
> Avevo visto questo talk di Giorgio Sironi all'agile day:
> https://vimeo.com/album/3674400/video/147027434
> 
> Si tratta della stessa cosa, immagino. Giusto?

Sì, vedi a 37:35.

Sulla pagina del talk non trovo le slide, e il pulsante "Talk" in basso
a sinistra non mi funziona né su Firefox, né su Chromium. :-P



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

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[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!

[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!

[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!

[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!

[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!

[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!

[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