<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 3, 2013 at 6:19 PM, Christopher Armstrong <span dir="ltr"><<a href="mailto:chris.armstrong@rackspace.com" target="_blank">chris.armstrong@rackspace.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, Jul 2, 2013 at 11:38 PM, Robert Collins<br>
<<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>> wrote:<br>
> Radix points out I missed the naunce that you're targeting the users<br>
> of python-novaclient, for instance, rather than python-novaclient's<br>
> own tests.<br>
><br>
><br>
> On 3 July 2013 16:29, Robert Collins <<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>> wrote:<br>
><br>
>>> What I'd like is for each client library, in addition to the actual<br>
>>> implementation, is that they ship a fake, in-memory, version of the API. The<br>
>>> fake implementations should take the same arguments, have the same return<br>
>>> values, raise the same exceptions, and otherwise be identical, besides the<br>
>>> fact<br>
>>> that they are entirely in memory and never make network requests.<br>
>><br>
>> So, +1 on shipping a fake reference copy of the API.<br>
>><br>
>> -1 on shipping it in the client.<br>
>><br>
>> The server that defines the API should have two implementations - the<br>
>> production one, and a testing fake. The server tests should exercise<br>
>> *both* code paths [e.g. using testscenarios] to ensure there is no<br>
>> skew between them.<br>
>><br>
>> Then the client tests can be fast and efficient but not subject to<br>
>> implementation skew between fake and prod implementations.<br>
>><br>
>> Back on Launchpad I designed a similar thing, but with language<br>
>> neutrality as a goal :<br>
>> <a href="https://dev.launchpad.net/ArchitectureGuide/ServicesRequirements#Test_fake" target="_blank">https://dev.launchpad.net/ArchitectureGuide/ServicesRequirements#Test_fake</a><br>
>><br>
>> And in fact, I think that that design would work well here, because we<br>
>> have multiple language bindings - Python, Ruby, PHP, Java, Go etc, and<br>
>> all of them will benefit from a low(ms or less)-latency test fake.<br>
><br>
> So taking the aspect I missed into account I'm much happier with the<br>
> idea of shipping a fake in the client, but... AFAICT many of our<br>
> client behaviours are only well defined in the presence of a server<br>
> anyhow.<br>
><br>
> So it seems to me that a fast server fake can be used in tests of<br>
> python-novaclient, *and* in tests of code using python-novaclient<br>
> (including for instance, heat itself), and we get to write it just<br>
> once per server, rather than once per server per language binding.<br>
><br>
> -Rob<br>
<br>
<br>
</div></div>I want to make sure I understond you. Let's say I have a program named<br>
cool-cloud-tool, and it uses python-novaclient, python-keystoneclient,<br>
and three other clients for OpenStack services. You're suggesting that<br>
its test suite should start up instances of all those OpenStack<br>
services with in-memory or otherwise localized backends, and<br>
communicate with them using standard python-*client functionality?<br>
<br>
I can imagine that being a useful thing, if it's very easy to do, and<br>
won't increase my test execution time too much.<br></blockquote><div><br></div><div>The easiest way to do this would be to set up a devstack instance to run your tests against, but that would increase test execution time by at least a few minutes.  So although something like this would not work well for unit tests it could be useful for integration tests.</div>

<div><br></div><div>Also I do not know of anyone using this for this type of testing yet, but someone always has to be first.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div class="im HOEnZb"><br>
--<br>
IRC: radix<br>
Christopher Armstrong<br>
Rackspace<br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<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>
</div></div></blockquote></div><br></div></div>