[Python] pytest e classi

[enrico franchi]

2015-10-27 19:29 GMT+00:00 Manlio Perillo <manlio.perillo a gmail.com>:

> 2015-10-27 15:51 GMT+01:00 enrico franchi <enrico.franchi a gmail.com>:
> > [...]
> >> La libreria standard di Go usa questo metodo, ed in effetti può essere
> >> visto come un problema.
> >
> >
> > In realta' non lo e'. Il punto e' che tutto questo discorso dei test e'
> nato
> > attorno ad una primitiva come assert che quando hai un problema
> > essenzialmente interrompe l'esecuzione li (tipicamente tirando
> un'eccezione)
> > e quindi le asserzioni successive non vengono eseguite.
> >
>
> Questo comportamento non è del tutto irragionevole.
>

No, non e' interamente irragionevole. Ma io credo che sia nato attorno al
fatto che esisteva assert, piuttosto che attorno al fatto che era la
semantica giusta.

Considera un test case in cui devo testare che un array non sia NULL e
> che contenga una serie di caratteri.
> Se il test assert p != NULL fallisce, il test case *deve* essere terminato.
>

Si. E viceversa se hai un oggetto di cui vuoi testare piu' proprieta' (cosa
di per se lecita: stai semplicemente controllando lo stato di *un* singolo
oggetto che e' l'output del SUT e semplicemente lo stato e' accessibile
tramite piu' proprieta') la cosa diventa scomoda. Diventa scomoda anche in
presenza dei "parametrized tests".

Entrambi gli approcci hanno vantaggi e svantaggi. A mio avviso la semantica
che non lancia l'eccezione e' complessivamente piu' flessibile (ovvero e'
meno pesante modellare la semantica in cui fermi il test sulla base di una
primitiva che di per se non lo ferma rispetto che il viceversa).

Non a caso in Go hai anche FailNow/Fatal* che hanno il comportamento di
fermare il test. Per cui semplicemente scrivi la cosa piu' coincisa
possibile a seconda di quello che vuoi fare.

Tempo fa avevo sviluppato una libreria per l'unit testing in C (oddio,
> quanto codice ho che non ho mai publicato...).
> La libreria usa il protocollo TAP, eppure avevo deciso di interrompere
> l'esecuzione della funzione di test
> in caso di fallimento, anche se non necessario (usando longjmp),
> perchè mi sembrava la scelta più ragionevole.
>

Eh... come dicevo, fanno tutti cosi', e' sensato farlo anche solo per
semplificare il ragionamento ai tuoi utenti.
Sebbene, a mio avviso, ancora una volta Go rompe gli schemi per fare la
cosa giusta.


>
> Non so perchè ero convinto che il test fosse interrotto in caso di
> fallimento, anche se la documentazione
> è chiara.
>
>
Ci sono anche funzioni che ti danno questa semantica. Semplicemente scegli
quello che ti serve.
Magari eri abituato ad usare quelle e non ti eri guardato quelle altre.


-- 
.
..: -enrico-
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20151028/f9f9480c/attachment.html>