<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 29, 2015 at 5:00 PM, Sławek Kapłoński <span dir="ltr"><<a href="mailto:slawek@kaplonski.pl" target="_blank">slawek@kaplonski.pl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
Thx for Your tips. So I should focus more on write new functional tests<br>
for ovs agent if there are missing some rather then doing unit tests for<br>
it?<br></blockquote><div><br></div><div>If a method is conceivably testable with unit tests (Without over relying on mock), that is preferable.</div><div>Failing that, functional tests are the way to go. The general idea is to test bottom up: Lots of unit</div><div>tests, fewer functional tests, fewer API/integration/fullstack tests, and even fewer Tempest scenario</div><div>tests. In the case of the OVS agent (And other Neutron agents that interact with the underlying hypervisor)</div><div>it is difficult to test the agent with unit tests effectively, which is why I encourage developers to test</div><div>via functional, mock-less tests, like the tests I linked you in my previous email.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="im HOEnZb"><br>
--<br>
Best regards / Pozdrawiam<br>
Sławek Kapłoński<br>
<a href="mailto:slawek@kaplonski.pl">slawek@kaplonski.pl</a><br>
<br>
</span><div class="HOEnZb"><div class="h5">On Mon, 28 Sep 2015, Assaf Muller wrote:<br>
<br>
> Generally speaking, testing agent methods that interact with the system<br>
> heavily with unit tests provide very little,<br>
> and arguably negative value to the project. Mocking internal methods and<br>
> asserting that they were called is a<br>
> clear anti-pattern to my mind. In Neutron-land we prefer to test agent code<br>
> with functional tests.<br>
> Since 'functional tests' is a very over-loaded term, what I mean by that is<br>
> specifically running the actual unmocked<br>
> code on the system and asserting the expected behavior.<br>
><br>
> Check out:<br>
> neutron/tests/functional/agent/test_ovs_lib<br>
> neutron/tests/functional/agent/test_l2_ovs_agent<br>
><br>
> On Mon, Sep 28, 2015 at 3:45 PM, Sławek Kapłoński <<a href="mailto:slawek@kaplonski.pl">slawek@kaplonski.pl</a>><br>
> wrote:<br>
><br>
> > Hello,<br>
> ><br>
> > I'm new developer who want to start contributing to neutron. I have some<br>
> > small experience with neutron already but I didn't do anything which I<br>
> > could push to upstream for now. So I searched for some bug on launchpad<br>
> > and I found such bug which I took:<br>
> > <a href="https://bugs.launchpad.net/neutron/+bug/1285893" rel="noreferrer" target="_blank">https://bugs.launchpad.net/neutron/+bug/1285893</a> and I started to<br>
> > checking how I can write new tests (I think that it is quite easy job to<br>
> > do for the beginning but maybe I'm wrong).<br>
> > Now I have some questions to You:<br>
> > 1. From test-coverage I can see that for example there is missing<br>
> > coverage like in lines 349-350 in method _restore_local_vlan_map(self) -<br>
> > should<br>
> > I create new test and call that metod to check if proper exception will<br>
> > be raised? or maybe it is not neccessary at all and such "one lines"<br>
> > missing coverage is not really needed to be checked? Or maybe it should<br>
> > be done in some different way?<br>
> ><br>
> > 2. What about tests for methods like: "_local_vlan_for_flat" which is<br>
> > not checked at all? should be created new test for such method? or maybe<br>
> > it should be covered by some different test?<br>
> ><br>
> > Thanks in advance for any advice and tips how to write such unit tests<br>
> > properly :)<br>
> ><br>
> > --<br>
> > Best regards / Pozdrawiam<br>
> > Sławek Kapłoński<br>
> > <a href="mailto:slawek@kaplonski.pl">slawek@kaplonski.pl</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>
> ><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>
<br>
</div></div><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>
<br></blockquote></div><br></div></div>