[openstack-dev] Proposal for including fake implementations in python-client packages

Robert Collins robertc at robertcollins.net
Wed Jul 3 04:29:43 UTC 2013


On 2 July 2013 09:08, Alex Gaynor <alex.gaynor at gmail.com> wrote:
> Hi all,
>
> I suspect many of you don't know me as I've only started to get involved in
> OpenStack recently, I work at Rackspace and I'm pretty involved in other
> Python
> open source stuff, notably Django and PyPy, I also serve on the board of the
> PSF. So hi<wave />!
>
> I'd like to propose an addition to all of the python-client libraries going
> forwards (and perhaps a requirement for future ones).
>
> 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.

-Rob

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



More information about the OpenStack-dev mailing list