> 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 tes
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, qu
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 (H
> 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
pag
> 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
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
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
"de
