<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 27, 2016 at 12:18 PM, Timur Nurlygayanov <span dir="ltr"><<a href="mailto:tnurlygayanov@mirantis.com" target="_blank">tnurlygayanov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi milan,<div><br></div><div>we have measured the test coverage for OpenStack components with coverage.py tool [1]. It is very easy tool and it allows measure the coverage by lines of code and etc. (several metrics are available).</div><div><br></div><div>[1] <a href="https://coverage.readthedocs.io/en/coverage-4.2/" target="_blank">https://coverage.<wbr>readthedocs.io/en/coverage-4.<wbr>2/</a></div></div></blockquote><div><br></div><div>coverage also supports aggregating results from multiple runs, so you can measure results from combinations such as:</div><div><br></div><div>1) Unit tests</div><div>2) Functional tests</div><div>3) Integration tests</div><div>4) 1 + 2</div><div>5) 1 + 2 + 3</div><div><br></div><div>To my eyes 3 and 4 make the most sense. Unit and functional tests are supposed to give you low level coverage, keeping in mind that 'functional tests' is an overloaded term and actually means something else in every community. Integration tests aren't about code coverage, they're about user facing flows, so it'd be interesting to measure coverage from integration tests, then comparing coverage coming from integration tests, and getting the set difference between the two: That's the area that needs more unit and functional tests.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 27, 2016 at 1:06 PM, Jordan Pittier <span dir="ltr"><<a href="mailto:jordan.pittier@scality.com" target="_blank">jordan.pittier@scality.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><span>On Tue, Sep 27, 2016 at 11:43 AM, milanisko k <span dir="ltr"><<a href="mailto:vetrisko@gmail.com" target="_blank">vetrisko@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Dear Stackers,<br></div><div>I'd like to gather some overview on the $Sub: is there some infrastructure in place to gather such stats? Are there any groups interested in it? Any plans to establish such infrastructure?<br></div></div></blockquote></span></span><div>I am working on such a tool with mixed results so far. Here's my approach taking let's say Nova as an example:</div><div><br></div><div>1) Print all the routes known to nova (available as a python-routes object:  nova.api.openstack.compute.AP<wbr>IRouterV21())</div><div>2) "Normalize" the Nova routes </div><div>3) Take the logs produced by Tempest during a tempest run (in logs/tempest.txt.gz). Grep for what looks like a Nova URL (based on port 8774)</div><div>4) "Normalize" the tested-by-tempest Nova routes.</div><div>5) Compare the two sets of routes</div><div>6) ????</div><div>7) Profit !!</div><div><br></div><div>So the hard part is obviously the normalizing of the URLs. I am currently using a tons of regex.... :) That's not fun.</div><div><br></div><div>I'll let you guys know if I have something to show.</div><div><br></div><div>I think there's real interest on the topic (it comes up every year or so), but no definitive answer/tool.</div><div><br></div><div>Cheers,</div><div>Jordan</div><div><br></div><div><br></div></div></div></div>

<br>
<a href="https://www.scality.com/backup/?utm_source=signatures&utm_medium=email&utm_campaign=backup2016" target="_blank"><img src="https://support.scality.com/Email_Footers/Current/Scality_Email_Footer.png"></a><br>______________________________<wbr>______________________________<wbr>______________<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.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br></blockquote></div><span class="gmail-HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><font color="#888888"><font color="#888888"><br></font></font><div style="font-family:arial;font-size:small">Timur,</div><div style="font-family:arial;font-size:small">Senior QA Manager</div><div style="font-family:arial;font-size:small">OpenStack Projects</div><div style="font-family:arial;font-size:small">Mirantis Inc</div></div></div></div></div></div></div></div></div>
</font></span></div>
<br>______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br></div></div>