<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 19, 2014 at 5:50 PM, Bjoern Michaelsen <span dir="ltr"><<a href="mailto:bjoern.michaelsen@canonical.com" target="_blank">bjoern.michaelsen@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Wed, Feb 19, 2014 at 05:20:19PM +0100, Markus Mohrhard wrote:<br>
> I doubt that. Look at the situation with the java tests where I'm the only<br>
> one who rewrites failing tests in c++. Most people just disable the test<br>
> that is failing and go on.<br>
<br>
</div>I just linked a bug that showed more 50 crash reports per day in the released<br>
product and was almost impossible to reproduce but was somewhat reproducable<br>
with the java tests. As for rewriting the Java tests -- the unoapi framework<br>
made that extra painful, though it should be somewhat saner for the complex<br>
tests. So given the choice, the Python tests should not imitate the unoapi<br>
test, to stay easily rewritable. <br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Also not that as I said in the other mail, I wouldnt want those tests to be run<br>
like unittests (on every build), but rather on each tagged release an<br>
prerelease build (with more runs optional) and we should aim to get them in a<br>
reasonable state by release (not ASAP/next day as for unittests) and no they<br>
are not blockers for a release in any way.<br>
<br></blockquote><div><br></div><div>So what you say is that you want to have python tests that test core functionality but don't want to run them regularly. Somehow that can't work. You have the two things you can do: <br>
<br>1) test core functionality with implementation details but that will rely on implementation details and will bit rot if you don't execute them<br></div><div>2) test our stable API but then you should not try to avoid implementation details which means you can't test most bugs<br>
<br></div><div>From what I see only point 2 makes sense for python tests especially if you want to run them only before releases and don't make them fail the build.<br><br></div><div>Regards,<br>Markus<br></div></div>
<br></div></div>