<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace;font-size:x-small"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 17, 2013 at 6:02 PM, Henry Gessau <span dir="ltr"><<a href="mailto:gessau@cisco.com" target="_blank">gessau@cisco.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="HOEnZb"><div class="h5">On Mon, Jun 17, at 7:01 pm, Joe Gordon <<a href="mailto:joe.gordon0@gmail.com">joe.gordon0@gmail.com</a>> wrote:<br>


> Hi All,<br>
><br>
> A patch to move the run_tests.sh script into oslo-incubator<br>
> (<a href="https://review.openstack.org/#/c/32736/" target="_blank">https://review.openstack.org/#/c/32736/</a>), has brought up the bigger<br>
> question of what is the future of './run_tests.sh.'<br>
><br>
> This seems like a topic that directly affects all developers, so it<br>
> sounded like it should be brought to the Mailing list.<br>
><br>
> Reasons to keep run_tests.sh:<br>
><br>
> * there is no possibility to run tests with testtools instead of testr.<br>
> This feature allows us to use the debugger.<br>
> * in some projects tox doesn't use a testr wrapper to report progress<br>
> while tests are running<br>
> * building the sdist can be slow (slow == noticeable)<br>
><br>
><br>
> Monty's Rant:<br>
><br>
> "So, I'm SUPER torn on this.<br>
><br>
> On the one hand, we use tox in the gate, and run_tests.sh hides that from<br>
> people and then they get confused about why some change they made to<br>
> run_tests.sh doesn't get reflected in the reality of the project.<br>
><br>
> On the other hand, what Victor says is true. We need to land a couple of<br>
> changes to upstream tox that would allow it to not run develop each time -<br>
> but we seem to have a hard time doing that.<br>
><br>
> On the third hand, we'd doing an INSANE amount of work to make working<br>
> with testing in a venv "easy" and what we've wound up with is a situation<br>
> where we have multiple competing incompatible ways of doing things.<br>
><br>
> Here's what I do: source .tox/py27/bin/activate testr run --parallel testr<br>
> run --parallel testr run some-test testr run --failing deactivate<br>
><br>
> Sometimes, if I'm being fancy, I'll do: virtualenv foo foo/bin/pip install<br>
> -r requirements.txt -r test-requirements.txt<br>
><br>
> I believe vish just installs the depends directly on his box and skips<br>
> venvs altogether.<br>
><br>
> It turns out that testr is a powerful tool with a nice UI. Instead of<br>
> putting wrappers around it, perhaps we should add support for our output<br>
> stream thing we like to it upstream. We should also add support to it for<br>
> dropping into a debugger directly, so that the testtools issue goes away.<br>
> Then we should land a patch to upstream tox to get it to do setup.py<br>
> develop instead of sdist+ install.<br>
><br>
> If we did that, we could have "run tox" be the simple answer for anyone<br>
> who just wants to run whatever the gate runs, because that will always<br>
> work. And if they want to do fancier things, they should learn about venvs<br>
> and testr.<br>
><br>
> However, if we ARE going to keep a run_tests.sh file in our trees, we<br>
> should certainly have a single copy and have it behave consistently.<br>
><br>
> Please note that some projects actually do just have run_tests.sh as a<br>
> thin wrapper around tox."<br>
><br>
><br>
> What do you think? Should we keep run_tests as is and port to oslo, or<br>
> should we revisit the role of run_tests.sh?<br>
><br>
><br>
</div></div>My vote is for run_tests.sh to contain just one line, "cat TESTING", and<br>
ensure the instructions are detailed and up to date. If course, it would be<br>
nice if all the projects gravitated towards the same TESTING.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><div class="gmail_default" style="font-family:'courier new',monospace;font-size:x-small"><br></div><div class="gmail_default" style="font-family:'courier new',monospace;font-size:x-small">

Post conversation with Lifeless and Clarkb on IRC, I'll change my answer slightly:</div><div class="gmail_default" style="font-family:'courier new',monospace;font-size:x-small"><br></div><div class="gmail_default" style="font-family:'courier new',monospace;font-size:x-small">

As long as I can do the following:</div><div class="gmail_default" style="font-family:'courier new',monospace;font-size:x-small"><br></div><div class="gmail_default" style="font-family:'courier new',monospace;font-size:x-small">

1. Run individual tests easily</div><div class="gmail_default" style="font-family:'courier new',monospace;font-size:x-small">2. Drop into PDB by setting a break-point</div><div class="gmail_default" style="font-family:'courier new',monospace;font-size:x-small">

3. Run WITHOUT virtual env</div><div class="gmail_default" style="font-family:'courier new',monospace;font-size:x-small">4. Not have to download a bunch of stuff or run some monster init every time I run tests on a fresh clone of a repo (see item 3)</div>

<br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_default" style="font-family:'courier new',monospace;font-size:x-small">I don't care if that's done via a wrapper script that calls a framework that supports the option (well I do care but we're already there so I'd prefer not to take it away), better documentation of how to run tests and how the frameworks operate or whatever.</div>

<br></div></div>