<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-10-27 19:29 GMT+00:00 Manlio Perillo <span dir="ltr"><<a href="mailto:manlio.perillo@gmail.com" target="_blank">manlio.perillo@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2015-10-27 15:51 GMT+01:00 enrico franchi <<a href="mailto:enrico.franchi@gmail.com">enrico.franchi@gmail.com</a>>:<br>
> [...]<br>
<span class="">>> La libreria standard di Go usa questo metodo, ed in effetti può essere<br>
>> visto come un problema.<br>
><br>
><br>
> In realta' non lo e'. Il punto e' che tutto questo discorso dei test e' nato<br>
> attorno ad una primitiva come assert che quando hai un problema<br>
> essenzialmente interrompe l'esecuzione li (tipicamente tirando un'eccezione)<br>
> e quindi le asserzioni successive non vengono eseguite.<br>
><br>
<br>
</span>Questo comportamento non è del tutto irragionevole.<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Considera un test case in cui devo testare che un array non sia NULL e<br>
che contenga una serie di caratteri.<br>
Se il test assert p != NULL fallisce, il test case *deve* essere terminato.<br></blockquote><div><br></div><div>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". </div><div><br></div><div>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). </div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Tempo fa avevo sviluppato una libreria per l'unit testing in C (oddio,<br>
quanto codice ho che non ho mai publicato...).<br>
La libreria usa il protocollo TAP, eppure avevo deciso di interrompere<br>
l'esecuzione della funzione di test<br>
in caso di fallimento, anche se non necessario (usando longjmp),<br>
perchè mi sembrava la scelta più ragionevole.<br></blockquote><div><br></div><div>Eh... come dicevo, fanno tutti cosi', e' sensato farlo anche solo per semplificare il ragionamento ai tuoi utenti.</div><div>Sebbene, a mio avviso, ancora una volta Go rompe gli schemi per fare la cosa giusta.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
</span>Non so perchè ero convinto che il test fosse interrotto in caso di<br>
fallimento, anche se la documentazione<br>
è chiara.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>Ci sono anche funzioni che ti danno questa semantica. Semplicemente scegli quello che ti serve.  </div><div>Magari eri abituato ad usare quelle e non ti eri guardato quelle altre.</div></div><br clear="all"><div><br></div>-- <br><div class="gmail_signature"> .<br>..: -enrico-</div>
</div></div>