415d76c2cf
The concept of the TestMaker was correct but in the process of making it less complex internally (with the addition of private method), it became clear that it was not being called correctly. Several variables being passed into make_one_test because they were considered per-test were not per-test but per file so they are now passed into __init__ instead. There is a data-not-behavior changing change in this commit: test['name'] is now processed to become full name of the test as used to name the HTTPTestCase (see the change in test_driver.py). This was done to support extracting the private methods in TestMaker. /cc @FND you were mostly correct about the loop that is possible across the make_one_test function, I guess I just can't mentall make that many changes in one go. |
||
|---|---|---|
| docs | ||
| gabbi | ||
| .gitignore | ||
| .testr.conf | ||
| .travis.yml | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| Makefile | ||
| README.rst | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-failskip.sh | ||
| test-limit.sh | ||
| test-requirements.txt | ||
| tox.ini | ||
README.rst
Gabbi
Gabbi is a tool for running HTTP tests where requests and responses are represented in a declarative YAML-based form. See the docs for more details on features and formats.
Gabbi is tested with Python 2.7, 3.4 and pypy and pypy3.
Tests can be run using unittest style test runners or from the command line with a gabbi-run script.
There is a gabbi-demo repository which provides a tutorial via its commit history. The demo builds a simple API using gabbi to facilitate test driven development.
Purpose
Gabbi works to bridge the gap between human readable YAML files that represent HTTP requests and expected responses and the obscured realm of Python-based, object-oriented unit tests in the style of the unittest module and its derivatives.
Each YAML file represents an ordered list of HTTP requests along with the expected responses. This allows a single file to represent a process in the API being tested. For example:
- Create a resource.
- Retrieve a resource.
- Delete a resource.
- Retrieve a resource again to confirm it is gone.
At the same time it is still possible to ask gabbi to run just one request. If it is in a sequence of tests, those tests prior to it in the YAML file will be run (in order). In any single process any test will only be run once. Concurrency is handled such that one file runs in one process.
These features mean that it is possible to create tests that are useful for both humans (as tools for improving and developing APIs) and automated CI systems.
Testing
To run the built in tests (the YAML files are in the directories
gabbi/gabbits_* and loaded by the file
gabbi/test_*.py), you can use tox:
tox -epep8,py27,py34Or if you have the dependencies installed (or a warmed up virtualenv) you can run the tests by hand and exit on the first failure:
python -m subunit.run discover -f gabbi | subunit2pyunitTesting can be limited to individual modules by specifying them after the tox invocation:
tox -epep8,py27,py34 -- test_driver test_handlers