gabbi promises relief by providing a language-agnostic, nicely readable and lightweight format for testing - and thus describing - HTTP APIs. Originally created as part of an effort to improve OpenStack’s APIs, it has since grown into a useful tool for anyone working with HTTP.

gabbi tests are simply YAML files that describe HTTP requests and responses. We’ll be using the wonderful httpbin for illustration purposes:

tests:

- name: supports unencrypted connections
  method: GET
  url: http://httpbin.org/
  status: 200

- name: supports SSL encryption
  method: GET
  url: https://httpbin.org/
  status: 200

method and status are optional, but it’s nice to be explicit. In fact, gabbi itself states that the name is “derived from ‘gabby’: excessively talkative” - i.e. gabbi prefers direct visibility and readability.

Of course we need to install gabbi in order to run these tests:

$ pip install gabbi

Using a virtual environment can help avoid sudo privileges or polluting our global packages directory.

Once that’s done, we can feed our YAML tests to gabbi:

$ gabbi-run < http.yaml
... E supports unencrypted connections
... E supports SSL encryption

ERROR: supports unencrypted connections
	[Errno 61] Connection refused
ERROR: supports SSL encryption
	[Errno 61] Connection refused
----------------------------------------------------------------------
Ran 2 tests in 0.015s

FAILED (errors=2)

Oops - I wasn’t connected to the internet. Of course we’d typically test a local development server instead, but that’s not important right now. Let’s try this again:

$ gabbi-run < http.yaml
... ✓ supports unencrypted connections
... ✓ supports SSL encryption

----------------------------------------------------------------------
Ran 2 tests in 0.681s

We don’t want to hard-code the target host, so let’s use paths instead of fully qualified URLs:

tests:

  - name: reports available HTTP methods
    method: OPTIONS
    url: /

    response_headers:
        allow: HEAD, OPTIONS, GET

  - name: front page returns HTML
    method: GET
    url: /

    status: 200
    response_headers:
        content-type: text/html; charset=utf-8

(Note that I added some vertical whitespace to separate request and response - that’s still valid YAML, of course.)

$ gabbi-run httpbin.org < http.yaml
... ✓ reports available HTTP methods
... ✓ front page returns HTML

----------------------------------------------------------------------
Ran 2 tests in 0.457s

That all seems pretty straightforward so far. Let’s ensure that the Allow header did in fact tell us the truth:

tests:

  - name: submitting data is not allowed
    method: POST
    url: /
    request_headers:
        content-type: text/plain
    data: lorem ipsum

    status: 405
$ gabbi-run httpbin.org < http.yaml
... ✓ submitting data is not allowed

As predicted, httpbin responded with 405 Method Not Allowed - clearly we’ll need to send our precious data to a different route:

tests:

  - name: form submission
    method: POST
    url: /post
    request_headers:
        content-type: application/x-www-form-urlencoded
    data: title=hello%20world&comment=lorem%20ipsum%21

    status: 200
$ gabbi-run httpbin.org < http.yaml
... ✓ form submission

Ah, there we go. Note that it’s our responsibility to encode the data there - that’s a little easier if we use JSON:

tests:

  - name: submitting JSON
    method: POST
    url: /post
    request_headers:
        content-type: application/json
    data:
        title: hello world
        comment: lorem ipsum dolor sit amet
$ gabbi-run httpbin.org < http.yaml
... ✓ submitting JSON

In fact, httpbin responds with JSON, returning in the response whatever data we submit in our request. We can use JSONPath to query that response data:

tests:

  - name: parsing JSON
    method: POST
    url: /post
    request_headers:
        accept: application/json
        content-type: application/json
    data:
        title: hello world
        comments: lorem ipsum dolor sit amet

    status: 200
    response_headers:
        content-type: application/json
    response_json_paths:
        $.json.title: hello world
        $.json.comments: lorem ipsum dolor sit amet
$ gabbi-run httpbin.org < http.yaml
... ✓ parsing JSON

It’s also possible to use data from the preceding response in a new request:

tests:

  - name: "consecutive redirects - step #1"
    method: GET
    url: /relative-redirect/2

    status: 302
    response_headers:
        location: /relative-redirect/1

  - name: "consecutive redirects - step #2"
    method: GET
    url: $LOCATION

    status: 302
    response_headers:
        location: /get
$ gabbi-run httpbin.org < http.yaml
... ✓ consecutive redirects - step #1
... ✓ consecutive redirects - step #2

Here we’re just using the Location header, but this technique also enables us to go full HATEOAS and test hypermedia APIs:

tests:

  - name: set up a hypermedia response
    method: PUT
    url: /put
    request_headers:
        accept: application/json
        content-type: application/json
    data:
        title: hello world
        links:
            next: http://httpbin.org/cookies/set?foo=bar

  - name: follow "next" link from preceding response
    method: GET
    url: $RESPONSE['$.json.links.next']

    status: 302
    response_headers:
        set-cookie: foo=bar; Path=/
$ gabbi-run httpbin.org < http.yaml
... ✓ set up a hypermedia response
... ✓ follow "next" link from preceding response

Obviously coercing httpbin into providing hypermedia responses is a bit of a hack, so we’ll stop here. Hopefully this is sufficient to get started - in a future post, we might expand on this with a more realistic example. We might also delve into gabbi’s extensibility, e.g. creating a custom response handler to query HTML responses with CSS selectors.

Feel free to join the IRC channel #gabbi on FreeNode or leave feedback via Twitter.

TAGS