<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 7, 2015 at 12:59 PM, Roman Prykhodchenko <span dir="ltr"><<a href="mailto:me@romcheg.me" target="_blank">me@romcheg.me</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">What I can extract now from this thread is that Fuel should switch to testr because of the following reasons:<div><br></div><div>- Diversity of tools is a bad idea on a project scale</div><div>- testrepository and related components are used in OpenStack Infra environment for much more tasks than just running tests</div><div>- py.test won’t be added to global-requirements so there always be a chance of another dependency hell</div><div>- Sticking to global requirements is an idea which is in the scope of discussions around Fuel.</div><div><br></div><div>Sounds like that’s the point when we should just file appropriate bugs and use testr in smaller components, e. g., Fuel Client, first and then try in in Nailgun.</div></div></blockquote><div><br></div><div>I'd say that using testr in the default tox targets and thus in the gate is the reasonable choice, for the reasons mentioned elsewhere. That said, I also think that it's also fair to allow alternate test runners on the local developer environment. You may have to make some tweaks from time to time, but most of the time py.test should be able to run the test suite supported by testr (this is not necessarily true for nose for example which doesn't support testscenarios AFAIK).<br><br>This way you standardize on the tools (testr remains the "source of truth"), but make local debugging much nicer.<br></div></div><br>-- <br></div><div class="gmail_extra">Thomas<br></div></div>