<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 27, 2015 at 1:30 PM, Manlio Perillo <span dir="ltr"><<a href="mailto:manlio.perillo@gmail.com" target="_blank">manlio.perillo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
Bello, non lo conoscevo; grazie.<br>
In effetti io uso solo unittest standard.<br></blockquote><div><br></div><div><a href="https://github.com/rik0/ParamUnittest">https://github.com/rik0/ParamUnittest</a><br></div><div><br></div><div>Feel free to contribute. </div><div><br></div><div>Che io sappia ci sono solo un paio di magagne se hai ereditarieta' complicata nei TestCase.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
</span>La libreria standard di Go usa questo metodo, ed in effetti può essere<br>
visto come un problema.</blockquote><div> </div><div>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.</div><div><br></div><div>La semantica dei test di Go invece e' basata attorno a primitive che marcano il test fallito, ma proseguono con l'esecuzione. Quindi, di fatto, buona parte dei problemi non ci sono piu'.</div><div>Personalmente la trovo una scelta eccellente, visto che e' molto piu' facile da usare e di default porta meno problemi di assert.</div></div><br clear="all"><div><br></div>-- <br><div class="gmail_signature"> .<br>..: -enrico-</div>
</div></div>