552c63849e
A 'gabbi' tox target is added which runs a declarative HTTP tests
described in YAML files in 'ceilometer/tests/gabbi/gabbits' and loaded by
'ceilometer/tests/gabbi/test_gabbi.py'. These are driven by the 'gabbi'
python package (available from PyPI).
tox and testr are configured to start and run the tests efficiently:
* a mongodb server, using multiple databases, is made available
* the API wsgi application is used directly via 'wsgi-intercept', no
web server required
* each YAML file is run as a sequence and where number of processors
allows, in a different test process
* individual tests can be requested in the usual way:
tox -egabbi -- <test pattern>
If this is done, all the tests prior to the one requested, from
its YAML file, will be run as ordered prerequisites.
* tox targets that already run the tests in ceilometer/tests will
also discover gabbi tests. If there is no mongodb, they will
be skipped.
A ConfigFixture does the necessary work of adjusting the configuration
and pipeline to use the mongodb database and nothing else. An
internal InterceptFixture uses wsgi-intercept to access the
ceilometer API. Each yaml file has its own intercepted host.
Fixtures are implemented as nested context managers that are declared
per YAML file, see ceilometer/gabbi/fixtures.py and fixtures-samples.yaml
for an example of how they can be used. Every yaml file uses at
least ConfigFixture.
YAML files can use a variety of strategies for formatting requests
and evaluating the correctness of response. See:
http://gabbi.readthedocs.org/en/latest/format.html
The YAML files included here test simple API features for creating and
retrieving samples. Subsequent patches can (and should) create
additional YAML files to describe more complex scenarios that cover
the entire API (for example alarms are not touched at all by this
patch).
Change-Id: I52551f88bc3beac4bf8a92afa45ac70cd97ffcec
Implements: blueprint declarative-http-tests
76 lines
2.0 KiB
YAML
76 lines
2.0 KiB
YAML
# Post a simple sample, sir, and the retrieve it in various ways.
|
|
fixtures:
|
|
- ConfigFixture
|
|
|
|
tests:
|
|
- name: post sample for meter
|
|
desc: post a single sample
|
|
url: /v2/meters/apples
|
|
method: POST
|
|
request_headers:
|
|
content-type: application/json
|
|
data: |
|
|
[
|
|
{
|
|
"counter_name": "apples",
|
|
"project_id": "35b17138-b364-4e6a-a131-8f3099c5be68",
|
|
"user_id": "efd87807-12d2-4b38-9c70-5f5c2ac427ff",
|
|
"counter_unit": "instance",
|
|
"counter_volume": 1,
|
|
"resource_id": "bd9431c1-8d69-4ad3-803a-8d4a6b89fd36",
|
|
"resource_metadata": {
|
|
"name2": "value2",
|
|
"name1": "value1"
|
|
},
|
|
"counter_type": "gauge"
|
|
}
|
|
]
|
|
|
|
response_json_paths:
|
|
$.[0].counter_name: apples
|
|
status: 200
|
|
response_headers:
|
|
content-type: application/json; charset=UTF-8
|
|
|
|
# TODO(chdent): No location header in the response!!!!
|
|
# - name: get sample
|
|
# desc: get the sample we just posted
|
|
# url: $LOCATION
|
|
|
|
- name: get samples for meter
|
|
desc: get all the samples at that meter
|
|
url: /v2/meters/apples
|
|
response_json_paths:
|
|
$.[0].counter_name: apples
|
|
$.[0].counter_volume: 1
|
|
$.[0].resource_metadata.name2: value2
|
|
|
|
- name: get resources
|
|
desc: get the resources that exist because of the sample
|
|
url: /v2/resources
|
|
response_json_paths:
|
|
$.[0].metadata.name2: value2
|
|
|
|
# NOTE(chdent): We assume that the first item in links is self.
|
|
# Need to determine how to express the more correct JSONPath here
|
|
# (if possible).
|
|
- name: get resource
|
|
desc: get just one of those resources via self
|
|
url: $RESPONSE['$[0].links[0].href']
|
|
response_json_paths:
|
|
$.metadata.name2: value2
|
|
|
|
- name: get samples
|
|
desc: get all the created samples
|
|
url: /v2/samples
|
|
response_json_paths:
|
|
$.[0].metadata.name2: value2
|
|
$.[0].meter: apples
|
|
|
|
- name: get one sample
|
|
desc: get the one sample that exists
|
|
url: /v2/samples/$RESPONSE['$[0].id']
|
|
response_json_paths:
|
|
$.metadata.name2: value2
|
|
$.meter: apples
|