The last blog post I made about gabbi was just under a year ago, announcing 1.29.0. Today I released 1.36.0. Several powerful features have been added in that interval, many of them by people other than me, which I take as a great sign of success.

Regularly, when using gabbi, I'll think "omg, this thing is so useful!" shortly followed by "omg, I made this thing!". But that's only partly true: gabbi exists because there was a void that I saw a way to fill and I was supported in that filling by my employer (Red Hat at the time) and the excellent input and feedback I got from my colleagues in the OpenStack telemetry project. Since then subsequent employers, colleagues and users of gabbi have continued to enable and shape its improvement. Thank you.

At its core, the entire point of gabbi is to help people make better HTTP APIs by making the use of HTTP methods and headers and the structure of request and response bodies as explicit, visible and tweakable as possible. I use it for test driven development: I start writing the API that I want or need in gabbi's YAML format and then start fixing the failing tests. This makes crufty annoyances more visible, sooner, and because gabbi's format is fairly raw it helps ensure that using the created API from lots of different clients is straightforward and there are few client specific warts. This is great because...

At its core, the entire point of HTTP APIs is to help people make diverse clients of services that do things you, the author, might never have predicted.

Gabbi has helped with that from the start, and with each release it gets a bit more helpful. Since 1.29.0, some very useful features have come along:

• The $HISTORY feature allows substitution from any previous test.
• JSON responses can be validated with JSON loaded from external files, not just the YAML file (as has always been true).
• Substitutions in JSONPath are now allowed on both the right and left hand side of expressions. In the past it was just the right side, which meant that dealing with dynamically created object parameters (such as a uuid) was challenging.
• The way in which each test in a gabbi YAML file is a member of a sequence of dependent tests can now be intentionally broken using the use_prior_test setting. This can make gabbi more useful when integrated with other tools.