<div dir="ltr">It would be better if we can document the scenarios / cases where individual tests make sense. As a developer this confuses me the most.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 3, 2015 at 10:21 AM, Takashi Yamamoto <span dir="ltr"><<a href="mailto:yamamoto@midokura.com" target="_blank">yamamoto@midokura.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">hi,<br>
<div><div class="h5"><br>
On Thu, Dec 3, 2015 at 11:19 AM, Armando M. <<a href="mailto:armamig@gmail.com">armamig@gmail.com</a>> wrote:<br>
> Hi Neutrinos,<br>
><br>
> I would like to share a proposal with you on how we could scale our<br>
> ever-growing testing needs, and at the same time, provide guidance to the<br>
> developers who care about the quality of the work they produce, and how they<br>
> can protect it from the dreadful regressions!<br>
><br>
> In [1] you will see a Decision Tree: the objective is to guide us in<br>
> deciding what is the best testing strategy for a feature, and what type of<br>
> support to expect from our CI engine. In a nutshell we have the following<br>
> basic options we can choose from:<br>
><br>
> Unit testing<br>
> Functional testing<br>
> API testing (*)<br>
> Fullstack testing<br>
> Scenario testing (**)<br>
><br>
> The bottom line is: we should tap into our existing infrastructure as much<br>
> as we can to try to minimize the amount of CI moving parts that allow us to<br>
> test the numerous features that Neutron has. Some work has to happen (as<br>
> highlighted below) before we can make this decision process as smooth as<br>
> possible. In particular:<br>
><br>
> (*) The API testing framework allows us to execute tempest-style API tests<br>
> against a Neutron live server. Assaf and I are working to address the<br>
> overlap between Tempest and this framework, and to ensure that there's a<br>
> clear demarcation to what test belongs to Tempest and what test belongs to<br>
> Neutron codebases respectively. More will follow in another thread, so stay<br>
> tuned. On the other hand, there's some work that needs to go into this<br>
> testing framework to make the server load up non-default extensions.<br>
><br>
> (**) This is something that Ihar started in [2]. I am still unclear on how<br>
> we intend to leverage this job and yet keep scenario-like tests for hardcore<br>
> Neutron features in the Neutron tree. Ihar is thinking QoS, I may be<br>
> thinking dpdk, someone else might be thinking to something yet again<br>
> different (don't get bogged down on the actual examples). We'll iterate on<br>
> [2], but I see it as an integral part of our end-to-end testing strategy.<br>
> More to follow.<br>
><br>
> As for new additional jobs that may come and go: I believe that we have to<br>
> revisit our approach to introduce experimental and non-voting jobs, and how<br>
> we make them stable and ultimately running as gate jobs and, long term,<br>
> having the features they tests supplant the ones they are meant to supersede<br>
> (think pecan, or dvr). I have an idea on how to address the non-voting<br>
> neglect conundrum, but I'll tackle it in another thread.<br>
><br>
> Finally, a word about projects that need testing with Neutron, advanced<br>
> services and beyond. The same way the neutron-lib initiative is tackling the<br>
> python side of the Neutron codebase as of now, we'll have to work to<br>
> identify the common pieces of functionality that will allow the reuse of the<br>
> testing machinery across multiple project, in a modular and decouple<br>
> fashion, so that when Neutron related projects want to integrate with the<br>
> Neutron CI engine, they will do so using good patterns rather than bad ones;<br>
> I believe that [3] is one of them, and that's why I have been pushing back.<br>
<br>
</div></div>can you explain what distinguishes good ones and bad ones?<br>
<span class=""><br>
><br>
> Feedback welcome, as I am sure I may overlooked something.<br>
><br>
> Cheers,<br>
> Armando<br>
><br>
> [1] <a href="https://wiki.openstack.org/wiki/Network/Testing" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/Network/Testing</a><br>
> [2] <a href="https://review.openstack.org/#/c/247697/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/247697/</a><br>
> [3] <a href="https://review.openstack.org/#/c/242925/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/242925/</a><br>
><br>
</span>> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div>