Note

This section provides a collection of questions with answers that don’t otherwise fit in the rest of the documentation. If something is missing, please create an issue.

As this document grows it will gain a more refined structure.

## General¶

### Is gabbi only for testing Python-based APIs?¶

No, you can use gabbi-run to test an HTTP service built in any programming language.

### How do I run just one test?¶

Each YAML file contains a sequence of tests, each test within each file has a name. That name is translated to the name of the test by replacing spaces with an _.

When running tests that are generated dynamically, filtering based on the test name prior to the test being collected will not work in some test runners. Test runners that use a --load-list functionality can be convinced to filter after discovery.

pytest does this directly with the -k keyword flag.

When using testrepository with tox as used in gabbi’s own tests it is possible to pass a filter in the tox command:

tox -epy27 -- get_the_widget


When using testtools.run and similar test runners it’s a bit more complicated. It is necessary to provide the full name of the test as a list to --load-list:

python -m testtools.run --load-list \
<(echo package.tests.test_api.yamlfile_get_the_widge.test_request)


### How do I run just one test, without running prior tests in a sequence?¶

By default, when you select a single test to run, all tests prior to that one in a file will be run as well: the file is treated as as sequence of dependent tests. If you do not want this you can adjust the use_prior_test test metadata in one of three ways:

• Set it in the YAML file for the one test you are concerned with.
• Set the defaults for all tests in that file.
• set use_prior_test to false when calling build_tests()

Be aware that doing this breaks a fundamental assumption that gabbi makes about how tests work. Any substitutions will fail.

## Testing Style¶

### Can I have variables in my YAML file?¶

Gabbi provides the \$ENVIRON substitution which can operate a bit like variables that are set elsewhere and then used in the tests defined by the YAML.

If you find it necessary to have variables within a single YAML file you take advantage of YAML alias nodes list this:

vars:
- &uuid_1 5613AABF-BAED-4BBA-887A-252B2D3543F8

tests:
- name: send a uuid to a post
POST: /resource