Open Stack

Radix points out I missed the naunce that you're targeting the users
of python-novaclient, for instance, rather than python-novaclient's
own tests.


On 3 July 2013 16:29, Robert Collins <robertc at robertcollins.net> wrote:

>> What I'd like is for each client library, in addition to the actual
>> implementation, is that they ship a fake, in-memory, version of the API. The
>> fake implementations should take the same arguments, have the same return
>> values, raise the same exceptions, and otherwise be identical, besides the
>> fact
>> that they are entirely in memory and never make network requests.
>
> So, +1 on shipping a fake reference copy of the API.
>
> -1 on shipping it in the client.
>
> The server that defines the API should have two implementations - the
> production one, and a testing fake. The server tests should exercise
> *both* code paths [e.g. using testscenarios] to ensure there is no
> skew between them.
>
> Then the client tests can be fast and efficient but not subject to
> implementation skew between fake and prod implementations.
>
> Back on Launchpad I designed a similar thing, but with language
> neutrality as a goal :
> https://dev.launchpad.net/ArchitectureGuide/ServicesRequirements#Test_fake
>
> And in fact, I think that that design would work well here, because we
> have multiple language bindings - Python, Ruby, PHP, Java, Go etc, and
> all of them will benefit from a low(ms or less)-latency test fake.

So taking the aspect I missed into account I'm much happier with the
idea of shipping a fake in the client, but... AFAICT many of our
client behaviours are only well defined in the presence of a server
anyhow.

So it seems to me that a fast server fake can be used in tests of
python-novaclient, *and* in tests of code using python-novaclient
(including for instance, heat itself), and we get to write it just
once per server, rather than once per server per language binding.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Cloud Services