<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 20, 2014 at 8:58 PM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On 05/19/2014 11:49 PM, Christopher Yeoh wrote:<br>
>><br>
> - if/else inlined in tests based on the "microversion mode" that is<br>
> being tested at the moment (perhaps least amount of "code" but cost is<br>
> readability)<br>
> - class inheritance (override specific bits where necessary - bit more<br>
> code, but readbility better?).<br>
> - duplicated tests (min sharing)<br>
<br>
</div>Realistically, the current approach won't scale to micro versions. We<br>
really won't be able to have 100 directories for Nova, or a 100 class<br>
inheritances.<br>
<br>
When a micro version happens, it will affect a small number of<br>
interfaces. So the important thing will be testing those interfaces<br>
before and after that change. We'll have to be really targeted here.<br>
Much like the way the database migration tests with data injection are.<br>
<br>
Honestly, I think this is going to be hard to fully map until we've got<br>
an interesting version sitting in front of us.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>So I agree that we won't be able to have a new directory for every microversion. But for the v2/v3 changes<br>we already have a lot of typical minor changes we'll need to handle. Eg.<br>
<br></div><div>- a parameter that has been renamed or removed (effectively the same thing from an API point of view)<br></div><div>- a success status code that has changed<br><br></div><div>Something like say a tasks API would I think be quite different because there would be a lot less shared code for the tests and so we'll need a different solution.<br>
<br></div><div>I guess what I'm saying is once we have a better idea of how the microversion interface will work then I think doing the work to minimise the code duplication on the tempest side is worth it because we have lots of examples of the sorts of cases we'll need to handle.<br>
</div><div><br>Regards,<br><br>Chris<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
        -Sean<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
</div></div><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>
<br></blockquote></div><br></div></div>