- A gabbi test is a data structure, currently formed as YAML, that represents a list of single HTTP requests and expected responses.
-
I'm going to show some sample tests and explain the features. These tests are running against a live server I have already started.
-
simple.yaml
- Unless you say otherwise, the default request method is
GET
and the test passes if the response code is200
.
- Unless you say otherwise, the default request method is
-
strings.yaml
- A response can be evaluated in a variety of ways with code called response handlers. There are some that are built in to gabbi or you can add your own. This one checks for strings in the response body.
-
deletefront.yaml
- Here we declare the request method to be used and the expected status.
- We also expect an
Allow
header in the response.
-
create-container.yaml
- Any test file can declare defaults that will be used for all the tests in the file (unless overriden).
- This verbose flag is what is causing the output you see after I show the test.
- Here we are
PUTting
a container owned by sam. When the value of the data key is not a string it is transformed into JSON. This is an object with a single keyowner
. - $LOCATION is replaced with the value of the location header of the previous response.
- One of the response handlers uses JSONPath. If you're not familiar with it it is basically a way to access members of a JSON object. This example says "give me the value of the owner key on the root object".
-
objects.yaml
- Another example of a JSONPath: this is listing the objects in the shed. There aren't any yet.
-
create-object.yaml
- This evaluation of the location header shows two features:
- Wrapping a header value in forward slashes makes it a regular expression.
- $SCHEME and $NETLOC are replaced with the real values associated with those names in a URL.
- So what we get here is a way of checking the full URL in the location header and validate that it has the form of a UUID on the end.
- This evaluation of the location header shows two features:
-
put-object.yaml
- When sending data to the server you can reference a file in the same directory.
- This looks like it may be a kitten, let's check.
-
list-objects.yaml
- This final example shows an additional feature: You can use JSONPath to access response data from the previous test in the current test. In this example we use it to create a URL but it can also be used pretty much anywhere including request headers and data and response headers and handlers.
As you can see there's a lot of flexibility. The server used as the backend here was developed using gabbi as the test harness. Tests are loaded using a file that looks like this. Note the intercept: no actual server is run. When we run the tests concurrently they are grouped according to the name of the file so all the tests one from one file will be in the same process.