Gabbi is a testing tool that I created at the beginning of this year. It uses a YAML-based representation of an HTTP request to test web APIs in a declarative fashion that is programming language agnostic. It works very well and has had some success in the Ceilometer and Gnocchi projects in OpenStack.

I think one of the reasons for that success is the combination of my background and the factors that caused Gabbi to be created. I've been developing web APIs with the specific intent of allowing people to gain access to and use information in whatever way they see fit, not just the way it was expected or designed to be used. For that unexpected access to work an API has to be very good about following the rules of HTTP and being transparent about its resources and capabilities.

Meanwhile when I stumbled into OpenStack last year, I felt like I landed in a world where "being transparent" and "unexpected access" were, to put it lightly, not design goals. A good descriptor for the services, the APIs, the code and even the test code is "turbid".

Gabbi was created because I needed a tool to clear away the murk and shine light into the APIs. I needed tests like this:

fixtures:
    - ConfigFixture
    - SampleDataFixture

tests:
    - name: query samples invalid field and non eq op
      url: /samples?q.field=non_valid_field_name&q.op=gt&q.value=3
      status: 400
      response_strings:
          - unrecognized field in query
          - 'Unknown argument: "non_valid_field_name"'

And lo and behold tests like that are also great at shining a light to where a new service needs to go to be a flexible API.