Gabbi is a python-based testing tool that can be used to declaratively test HTTP APIs using a YAML-based format.

Gabbi 1.29.0 has just been released. Since it has been some time since the last posting about gabbi here are some updates on how things have changed in the past few months.

For a brief summary of everything since 1.0, you can see the Release Notes.

urllib3 instead of httplib2

The inner workings of gabbi is a series of HTTP requests. In the earliest versions these were performed by the httplib2 library. I've always loved the essential simplicity of httplib2 but of late it has not received much maintenance.

Meanwhile requests and its lower level library urllib3 have become the defacto HTTP client tools for Python.

So now gabbi uses that.

Support for pytest

Gabbi was born in the OpenStack world. There the massive continuous integration system is firmly devoted to testrepository and subunit. To avoid complexity and delays, gabbi was originally built to be aligned with those tools. This meant taking on something of a classic Python unitest form.

And not working with pytest.

I've always loved the essential simplicity of pytest...

...so I wanted to be sure to be get gabbi working with it, especially since gabbi is based on something I did in TiddlyWeb several years ago using what are called "yield tests" in pytest. In version 1.17.0 of gabbi support for pytest was released.

...but of late is has lost some of that simplicity.

When pytest 3.0 was released, yield tests were deprecated. Running gabbi tests from pytest would spew a bunch of warnings about how they would stop working in 4.0. In version 1.29.0 a new way of doing things that avoids the warnings has been released.

It's still not properly the canonical pytest-way, but with luck we'll get there eventually.

Content Handlers

From the outset, gabbi was designed to support testing of JSON-based APIs. JSONPath support has been built in from the start. With the advent of Content Handlers it is now easy to add extensions to gabbi to manage and evaluate request and response bodies in different formats.

Content Handlers are an interface to load and dump a specific content-type and perform tests against the data.

gabbihtml provides an (incomplete) example. It has two main features:

• structured information represented in the data test key can be loaded and sent as an application/x-www-form-urlencoded string
• HTML response bodies can be parsed to a DOM and evaluted using a css-selector style syntax.

The test file may be illuminating.

Updates to gabbi-run

gabbi-run provides a command line tool to run gabbi tests against any running web server. There have been several changes to make it more effective:

• It can now accept a list of filenames as command line arguments, instead of only taking data from stdin.
• Files loaded with <@ are pathnames relative to the directory of the currently loaded file (or the current working directory if reading from stdin). In the past, files were only in the current directory.
• There's now a --verbose flag which will cause all tests in a session to output more information about the requests being made.

Next

The above changes achieve most of the goals set out in Planning Gabbi 2.0 so why isn't there a 2.0? Because all the changes have been made in backwards compatible way. A gabbi YAML file created in the early days will still work.

There are still quite a number of things to do to make gabbi excellent. Some of those things are listed on the ideas page in the wiki. Most changes are related to cleaning up the structure of the code to:

• make it less tied to unittest
• do pytest dynamic test generation in a way that is more aligned with modern pytest techniques
• separate concerns so the code is more composable and comprehensible

If you have suggestions, questions, or want to help, leave a comment here, make an issue, or join us in #gabbi on freenode IRC.