<div dir="ltr"><br>
<div class="gmail_quote">On Tue, Jul 28, 2009 at 12:10 AM, Laurent Ploix <span dir="ltr"><<a href="mailto:laurent.ploix@gmail.com">laurent.ploix@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div> </div>
<div>Could you explain what made you consider pyFit and Robot an "overhead compare to the benefit" ? That may help people suggest other alternatives... (and maybe consider building another framework if they agree)</div>
<div><br></div>
<div>laurent</div></blockquote>
<div> </div>
<div>I'll start saying what are the benefits:</div>
<div>* easy to read test that anyone can understand (better in pyFit less in Robot)</div>
<div>* integration with Hudson (Continues Integration) - (good in PyFit , Robot and Nose...)</div>
<div>* fancy reports on the tests (this is not that important to us)</div>
<div>* Connecting between a text/table based Test Case and the real Code test.</div>
<div> </div>
<div>overhead:</div>
<div>* When a test fails in Pyfit its not clear why. if it failed with exception then its very unreadable.</div>
<div>* PyFit requires annoying metadata to be written on each table.</div>
<div>* Robot does provide better failure analysis but doesn't provide the clear PyFit test case definition.</div>
<div>* Mapping keywords in Robot is not hard but making the test-case look like a test case in Word requires a lot of keywords and work.</div>
<div> </div>
<div>none of the frameworks provided in kind of stub object to help testing without the GUI layer.</div>
<div> </div>
<div>Thanks,</div>
<div>Yoav.</div>
<div> </div>
<div> </div>
<div> </div></div></div>