<div dir="ltr"><div style>Maru,</div><div style><br></div>I've seen your changes and I'm totally fine with them.<div style>I think it makes sense for you to lead this part of the discussion, since you've studied the subject much more than me!</div>
<div><br><div style>One caveat: during the discussion let's remember to keep focused on how we should rework the unit tests, avoiding the risk of falling into a discussion on unit vs functional vs integration tests, which, even if interesting, is probably not what the audience might expect from this session.</div>
</div><div style><br></div><div style>See you tomorrow,</div><div style>Salvatore</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 14 April 2013 19:22, Maru Newby <span dir="ltr"><<a href="mailto:marun@redhat.com" target="_blank">marun@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Salvatore,<br>
<br>
I hope you don't mind, but I've fleshed out the 'types of tests' section to provide more background.  It was only afterwards that I thought of checkpointing before I started to allow you to revert if my changes don't suit your intensions.<br>

<br>
My goal was to achieve some clarity on different types of testing so that reviewers will be in a better position to evaluate test quality.<br>
<br>
Examples for refactoring to follow.<br>
<br>
Cheers,<br>
<br>
<br>
Maru<br>
<div class="HOEnZb"><div class="h5"><br>
On Apr 12, 2013, at 9:33 AM, Salvatore Orlando <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>> wrote:<br>
<br>
> I am preparing an etherpad for this session - <a href="https://etherpad.openstack.org/havana-quantum-unittests" target="_blank">https://etherpad.openstack.org/havana-quantum-unittests</a><br>
> There is a session for restructuring unit tests in which you can put links to code samples we can discuss in the summit session.<br>
> I am unable to give an exact timing for walking through the examples, as it depends on how many samples we have. Looking at the other topics in the etherpad, and the time it might take to discuss them, I guess we can spend about half of the session discussing code.<br>

><br>
> Salvatore<br>
><br>
><br>
> On 12 April 2013 09:12, Maru Newby <<a href="mailto:marun@redhat.com">marun@redhat.com</a>> wrote:<br>
> Hi Salvatore,<br>
><br>
> I will be happy to provide some samples and walk through refactoring them.  How much time would intend for such an exercise so that I could target my effort?<br>
><br>
> Cheers,<br>
><br>
><br>
> Maru<br>
><br>
> On Apr 11, 2013, at 2:04 PM, Salvatore Orlando <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>> wrote:<br>
><br>
> > [REPOSTING THIS REPLY]<br>
> ><br>
> > Please let me know if others want to jump in the discussion on Quantum unit tests<br>
> ><br>
> > Hi Maru,<br>
> ><br>
> > thanks for contributing to this topic.<br>
> > More comments inline.<br>
> ><br>
> ><br>
> > I was thinking of providing code samples during the summit session explaining how existing tests could be refactored. If you can provide some samples it would be great; also if you're ok with walking the audience through these samples, that would be awesome!<br>

> ><br>
> > Salvatore<br>
> ><br>
> ><br>
> > On 4 April 2013 03:34, Maru Newby <<a href="mailto:marun@redhat.com">marun@redhat.com</a>> wrote:<br>
> > Hi Salvatore,<br>
> ><br>
> > I'm working on a patch to swap pep8 for flake8, which will increase the automation of mechanical review.  In the process of doing the cleanup required for the patch, I have seen some ways that quantum's test suite could be improved:<br>

> ><br>
> >  -  An api method and its serialization format (xml, json) are orthogonal (or should be) and could be tested as such.  For plugins that test both serialization formats for each api method, test execution time is effectively doubled with no benefit to coverage.<br>

> ><br>
> > I totally agree. Once we get past the WSGI layer, there is not difference between the JSON or the XML use case. The Serialization tests should just validate data serialization and deserialization.<br>
> ><br>
> ><br>
> >  - Many plugins contain duplicate code and tests (e.g. get_port_from_device and its associated tests appear in each of the nec, openvswitch, ryu, and linuxbridge plugins).  Common code could be factored out and tested only once.<br>

> ><br>
> > That's another good point that I wanted to address. It seems these tests have the same coverage, so, as you say, they should be factored out in a test module aimed at covering that specific functionality.<br>

> ><br>
> ><br>
> > - Many quantum tests evaluate low-level functionality through a web api rather than isolating the functionality under test.  Writing more focused unit tests (and fewer functional and integration tests ala <a href="http://www.martinfowler.com/bliki/TestPyramid.html" target="_blank">http://www.martinfowler.com/bliki/TestPyramid.html</a>) could allow for better coverage at a lower cost in both maintenance and execution.<br>

> ><br>
> > This is the first goal of reworking our unit tests. We have always been aware that those were not unit tests. However, those were the closest think we could provide to a gatetests. Now that we have proper gate tests - we should make sure our unit tests are proper unit tests! Also, it would be good to discuss what to make of the current unit tests, which are probably suitable for some sort of automated functional testing.<br>

> ><br>
> ><br>
> > The technical aspects of these potential improvements are straightforward, but will require a degree of developer and reviewer education to ensure that they are properly implemented and maintained going forward.  Do you think the summit session you've proposed would be an appropriate venue, or should it be done separately?<br>

> ><br>
> > I think the summit session is just a starter. 'Education' should be enforced via code reviews. The main goal of the summit session is achieve consensus on the general direction, identify priorities, and possibly resources.<br>

> ><br>
> ><br>
> ><br>
> > Cheers,<br>
> ><br>
> ><br>
> > Maru<br>
> ><br>
> ><br>
> > On 3 April 2013 18:34, Maru Newby <<a href="mailto:marun@redhat.com">marun@redhat.com</a>> wrote:<br>
> > Hi Salvatore,<br>
> ><br>
> > I'm working on a patch to swap pep8 for flake8, which will increase the automation of mechanical review.  In the process of doing the cleanup required for the patch, I have seen some ways that quantum's test suite could be improved:<br>

> ><br>
> >  -  An api method and its serialization format (xml, json) are orthogonal (or should be) and could be tested as such.  For plugins that test both serialization formats for each api method, test execution time is effectively doubled with no benefit to coverage.<br>

> ><br>
> >  - Many plugins contain duplicate code and tests (e.g. get_port_from_device and its associated tests appear in each of the nec, openvswitch, ryu, and linuxbridge plugins).  Common code could be factored out and tested only once.<br>

> ><br>
> > - Many quantum tests evaluate low-level functionality through a web api rather than isolating the functionality under test.  Writing more focused unit tests (and fewer functional and integration tests ala <a href="http://www.martinfowler.com/bliki/TestPyramid.html" target="_blank">http://www.martinfowler.com/bliki/TestPyramid.html</a>) could allow for better coverage at a lower cost in both maintenance and execution.<br>

> ><br>
> > The technical aspects of these potential improvements are straightforward, but will require a degree of developer and reviewer education to ensure that they are properly implemented and maintained going forward.  Do you think the summit session you've proposed would be an appropriate venue, or should it be done separately?<br>

> ><br>
> > Cheers,<br>
> ><br>
> ><br>
> > Maru<br>
> ><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>