Back when I used to spend a lot of time building wiki software, those of us in the trade would use the term guerrilla wiki to refer to wiki software that you could easily spin up on a desktop or handy machine sitting under a departmental desk. This was done to get around organizational processes that either restricted running useful tools, or restricted useful information sharing. A motivated team would run their own tools and get on with getting stuff done, freed from the friction of imposed process.

Now, developing in the OpenStack environment, friction can be found in a variety of places, probably different for every contributor. I struggle to overcome the friction involved when reading and writing the tests associated with code, especially in nova. While the active code is convoluted enough, the test code blows my hair back.

As someone who prefers to do test driven development, friction in the test writing process is friction right at the start, a big hurdle to overcome.

In a change I'm working on right now, to explore how an API for something called "resource pools" might work, I decided to shoehorn gabbi into the test harness and code the API test first. There are plans in the works to use gabbi in an official capacity in nova, but in the meantime to keep me moving in a useful fashion without the friction I stubbed in the bare minimum requirements:

• A test loader that points gabbi at the YAML files that represent the HTTP requests being made.
• A config fixture which establishes the minimum configuration settings and services to run a WSGI application with a persistence layer.

The result of this work has meant that I've been able to explore the API from the perspective of HTTP, rather than the code, quickly finding a fair few gaps and bugs in the specs and code on which the API will depend. I will inevitably have to write standard nova tests, but that will at least be after the exploratory stage is complete. At that time I will, because of the test driven creation of the API, be confident that it behaves in a way that a random HTTP client expects, not just nova test code.