if we have many requirements they could interfere with your requirements

The code being unit-tested should not be able to tell the difference of whether it is working with Stack-In-A-Box or the real thing

there should be nothing special about setting up the test

if you don’t turn on Stack-In-A-Box then the code should be able to call the real thing

Why not use framework X?

A couple of frameworks and tools were considered, but they did not quite meet the goals above.

For instance, mimic (https://github.com/rackerlabs/mimic) is a great tool for testing multiple things. However, you have to start/stop it separately from your tests, and each test is configured through a series of HTTP calls to Mimic itself.

On the other hand, pretenders (https://github.com/pretenders) has a nice framework too, but it does not provide a way to emulate an integrated application that requires a series of dependent calls that modify each other.

What’s Provided?

Here’s what is currently provided:

An easy to build Service object and end-point registration that is plug-in-play with StackInABox

A plug-in-play utility set for several testing frameworks so you the developer can choose which fits your needs best

An example HelloWorld Service to show the basics

The start of support StackInABox services for testing against OpenStack/Rackspace APIs

It’s a work in progress. Here’s the list of current targets in-order:

Keystone v2

Keystone v3

Swift

Thus far Keystone v2 provides end-points for:

Listing tenants

Listing users

It also has support in the backend for:

tenant (add/remove/enable/disable)

users (add/remove/enable/disable, apikey, password)

tokens (add/remove, revoke, validate, admin tokens)

roles (add, assign)

Working with Frameworks

Stack-In-A-Box does not itself provide a socket interception framework.
Out-of-the-box it supports the following frameworks:

Requests Mock

requests-mock works well with class-based tests, however, it does require that you use the Python requests API. If you use requests-mock directly than you also have to configure requests.session.Session objects and setup your code to use them. However, Stack-In-A-Box makes that unnecessary by providing thread-based session objects that are automatically registered and patching requests to return them automatically. Thus you can either use a Session object directly or just use the nice calls that requests provides and your tests will still just work.