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
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.
and its lower level library
urllib3 have become the defacto HTTP
client tools for Python.
So now gabbi uses that.
Support for pytest
in the OpenStack world. There the massive continuous integration
system is firmly devoted to
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
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
several years ago using what are called "yield tests" in pytest. In
1.17.0 of gabbi support for pytest was released.
...but of late is has lost some of that simplicity.
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
that avoids the warnings has been released.
It's still not properly the canonical pytest-way, but with luck we'll get there eventually.
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
datatest key can be loaded and sent as an
- 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
- 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
--verboseflag which will cause all tests in a session to output more information about the requests being made.
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
- 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.