gabbi Package¶
case
Module¶
A single HTTP request represented as a subclass of unittest.TestCase
The test case encapsulates the request headers and body and expected response headers and body. When the test is run an HTTP request is made using httplib2. Assertions are made against the reponse.
-
class
gabbi.case.
HTTPTestCase
(methodName='runTest')¶ Bases:
unittest.case.TestCase
Encapsulate a single HTTP request as a TestCase.
If the test is a member of a sequence of requests, ensure that prior tests are run.
To keep the test harness happy we need to make sure the setUp and tearDown are only run once.
-
assert_in_or_print_output
(expected, iterable)¶
-
base_test
= {'status': '200', 'xfail': False, 'redirects': False, 'verbose': False, 'query_parameters': {}, 'url': '', 'skip': '', 'name': '', 'ssl': False, 'request_headers': {}, 'poll': {}, 'data': '', 'method': 'GET', 'desc': ''}¶
-
static
extract_json_path_value
(data, path)¶ Extract the value at JSON Path path from the data.
The input data is a Python datastructre, not a JSON string.
-
replace_template
(message)¶ Replace magic strings in message.
-
response_handlers
= []¶
-
run
(result=None)¶ Store the current result handler on this test.
-
setUp
()¶
-
tearDown
()¶
-
test_request
()¶ Run this request if it has not yet run.
If there is a prior test in the sequence, run it first.
-
-
exception
gabbi.case.
ServerError
¶ Bases:
exceptions.Exception
A catchall ServerError.
-
gabbi.case.
potentialFailure
(func)¶ Decorate a test method that is expected to fail if ‘xfail’ is true.
driver
Module¶
Generate HTTP tests from YAML files
Each HTTP request is its own TestCase and can be requested to be run in isolation from other tests. If it is a member of a sequence of requests, prior requests will be run.
A sequence is represented by an ordered list in a single YAML file.
Each sequence becomes a TestSuite.
An entire directory of YAML files is a TestSuite of TestSuites.
-
exception
gabbi.driver.
GabbiFormatError
¶ Bases:
exceptions.ValueError
An exception to encapsulate poorly formed test data.
-
class
gabbi.driver.
TestBuilder
¶ Bases:
type
Metaclass to munge a dynamically created test.
-
required_attributes
= {'has_run': False}¶
-
-
gabbi.driver.
build_tests
(path, loader, host=None, port=8001, intercept=None, test_loader_name=None, fixture_module=None, response_handlers=None, prefix=None)¶ Read YAML files from a directory to create tests.
Each YAML file represents an ordered sequence of HTTP requests.
Parameters: - path – The directory where yaml files are located.
- loader – The TestLoader.
- host – The host to test against. Do not use with
intercept
. - port – The port to test against. Used with
host
. - intercept – WSGI app factory for wsgi-intercept.
- test_loader_name – Base name for test classes. Rarely used.
- fixture_module – Python module containing fixture classes.
- response_handers – ResponseHandler classes.
- prefix – A URL prefix for all URLs that are not fully qualified.
Return type: TestSuite containing multiple TestSuites (one for each YAML file).
-
gabbi.driver.
load_yaml
(yaml_file)¶ Read and parse any YAML file. Let exceptions flow where they may.
-
gabbi.driver.
test_suite_from_yaml
(loader, test_base_name, test_yaml, test_directory, host, port, fixture_module, intercept, prefix=None)¶ Generate a TestSuite from YAML data.
-
gabbi.driver.
test_update
(orig_dict, new_dict)¶ Modify test in place to update with new data.
fixture
Module¶
Manage fixtures for gabbi at the test suite level.
-
class
gabbi.fixture.
GabbiFixture
¶ Bases:
object
A context manager that operates as a fixture.
Subclasses must implement
start_fixture
andstop_fixture
, each of which contain the logic for stopping and starting whatever the fixture is. What a fixture is is left as an exercise for the implementor.These context managers will be nested so any actual work needs to happen in
start_fixture
andstop_fixture
and not in__init__
. Otherwise exception handling will not work properly.-
start_fixture
()¶ Implement the actual workings of starting the fixture here.
-
stop_fixture
()¶ Implement the actual workings of stopping the fixture here.
-
-
exception
gabbi.fixture.
GabbiFixtureError
¶ Bases:
exceptions.Exception
Generic exception for GabbiFixture.
-
class
gabbi.fixture.
InterceptFixture
(host, port, app, prefix)¶ Bases:
gabbi.fixture.GabbiFixture
Start up the wsgi intercept. This should not be called directly.
-
start_fixture
()¶
-
stop_fixture
()¶
-
-
class
gabbi.fixture.
SkipAllFixture
¶ Bases:
gabbi.fixture.GabbiFixture
A fixture that skips all the tests in the current suite.
-
start_fixture
()¶
-
-
gabbi.fixture.
nest
(*args, **kwds)¶ Nest a series of fixtures.
This is duplicated from
nested
in the stdlib, which has been deprecated because of issues with how exceptions are difficult to handle during__init__
. Gabbi needs to nest an unknown number of fixtures dynamically, so thewith
syntax that replacesnested
will not work.
handlers
Module¶
Handlers for processing the body of a response in various ways.
A response handler is a class that adds functionality for making assertions about an HTTP response.
A subclass may implement two methods: action
and preprocess
.
preprocess
takes one argument, the TestCase
. It is called exactly
once for each test before looping across the assertions. It is used, rarely,
to copy the test.output
into a useful form (such as a parsed DOM).
action
takes two or three arguments. If test_key_value
is a list
action
is called with the test case and a single list item. If
test_key_value
is a dict then action
is called with the test case
and a key and value pair.
-
class
gabbi.handlers.
HeadersResponseHandler
(test_class)¶ Bases:
gabbi.handlers.ResponseHandler
Compare expected headers with actual headers.
If a header value is wrapped in
/
it is treated as a raw regular expression.-
action
(test, header, value)¶
-
test_key_suffix
= 'headers'¶
-
test_key_value
= {}¶
-
-
class
gabbi.handlers.
JSONResponseHandler
(test_class)¶ Bases:
gabbi.handlers.ResponseHandler
Test for matching json paths in the json_data.
-
action
(test, path, value)¶ Test json_paths against json data.
-
test_key_suffix
= 'json_paths'¶
-
test_key_value
= {}¶
-
-
class
gabbi.handlers.
ResponseHandler
(test_class)¶ Bases:
object
-
action
(test, item, value=None)¶ Test an individual entry for this response handler.
If the entry is a key value pair the key is in item and the value in value. Otherwise the entry is considered a single item from a list.
-
preprocess
(test)¶ Do any pre-single-test preprocessing.
-
test_key_suffix
= ''¶
-
test_key_value
= []¶
-
-
class
gabbi.handlers.
StringResponseHandler
(test_class)¶ Bases:
gabbi.handlers.ResponseHandler
Test for matching strings in the the response body.
-
action
(test, expected, value=None)¶
-
test_key_suffix
= 'strings'¶
-
test_key_value
= []¶
-
suite
Module¶
A TestSuite for containing gabbi tests.
This suite has two features: the contained tests are ordered and there are suite-level fixtures that operate as context managers.
-
class
gabbi.suite.
GabbiSuite
(tests=())¶ Bases:
unittest.suite.TestSuite
A TestSuite with fixtures.
The suite wraps the tests with a set of nested context managers that operate as fixtures.
If a fixture raises unittest.case.SkipTest during setup, all the tests in this suite will be skipped.
-
run
(result, debug=False)¶ Override TestSuite run to start suite-level fixtures.
To avoid exception confusion, use a null Fixture when there are no fixtures.
-
runner
Module¶
-
gabbi.runner.
run
()¶ Run simple tests from STDIN.
This command provides a way to run a set of tests encoded in YAML that is provided on STDIN. No fixtures are supported, so this is primarily designed for use with real running services.
Host and port information may be provided in three different ways:
- In the URL value of the tests.
- In a host or host:port argument on the command line.
- In a URL on the command line.
An example run might looks like this:
gabbi-run example.com:9999 < mytest.yaml
or:
gabbi-run http://example.com:999 < mytest.yaml
It is also possible to provide a URL prefix which can be useful if the target application might be mounted in different locations. An example:
gabbi-run example.com:9999 /mountpoint < mytest.yaml
or:
gabbi-run http://example.com:9999/mountpoint < mytest.yaml
Use -x or –failfast to abort after the first error or failure:
gabbi-run -x example.com:9999 /mountpoint < mytest.yamlOutput is formatted as unittest summary information.
utils
Module¶
Utility functions grab bag.
-
gabbi.utils.
decode_response_content
(header_dict, content)¶ Decode content to a proper string.
-
gabbi.utils.
extract_content_type
(header_dict)¶ Extract content-type from headers.
-
gabbi.utils.
get_colorizer
(stream)¶ Return a function to colorize a string.
Only if stream is a tty .
-
gabbi.utils.
not_binary
(content_type)¶ Decide if something is content we’d like to treat as a string.
httpclient
Module¶
Subclass of Http class for verbosity.
-
class
gabbi.httpclient.
VerboseHttp
(**kwargs)¶ Bases:
httplib2.Http
A subclass of Http that verbosely reports on activity.
If the output is a tty or
GABBI_FORCE_COLOR
is set in the environment, then output will be colorized according toCOLORMAP
.Output can include request and response headers, request and response body content (if of a printable content-type), or both.
The color of the output has reasonable defaults. These may be overridden by setting the following environment variables
- GABBI_CAPTION_COLOR
- GABBI_HEADER_COLOR
- GABBI_REQUEST_COLOR
- GABBI_STATUS_COLOR
to any of: BLACK RED GREEN YELLOW BLUE MAGENTA CYAN WHITE
-
COLORMAP
= {'status': 'CYAN', 'caption': 'BLUE', 'request': 'CYAN', 'header': 'YELLOW'}¶
-
HEADER_BLACKLIST
= ['status']¶
-
REQUEST_PREFIX
= '>'¶
-
RESPONSE_PREFIX
= '<'¶
-
gabbi.httpclient.
get_http
(verbose=False, caption='')¶ Return an Http class for making requests.