On Wed, 25 May 2016, Andrew Laski wrote:
After reading this my first thought is that gabbi would handle what I'm
testing in
https://review.openstack.org/#/c/263927/33/nova/tests/functional/wsgi/test_servers.py,
or any of the other tests in that directory. Does that seem accurate?
And what would the advantage of gabbi be versus what I have currently
written?
Yes, things like that seem like they could be a pretty good candidate.
Assuming you had a GabbiFixture subclass that did what you're doing in
your setUp()[1] and test loader[2] then the gabbi file would look
something like this (untested, but if you want to try this together
tomorrow I reckon we could make it go pretty quickly):
```yaml
fixtures:
- LaskiFixture
tests:
- name: create a server
POST: /servers
request_headers:
content-type: application/json
data:
server:
name: foo
# the fixture injects this value
imageRef: $ENVIRON['image_ref']
flavorRef: 1
status: 201
response_headers:
# check headers however you like here
- name: get the server
# this assumes the post above had a location response
# header
GET: $LOCATION
response_json_paths:
$.server.name: foo
$.server.image.id: $ENVIRON['image_ref']
$.server.flavor.id: 1
- name: delete the server
DELETE: $LAST_URL
status: 204
- name: make sure it really is gone
GET: $LAST_URL
status: 404
```
To me the primary advantages are:
* cleaner representation of the request response cycle of a sequence
of requests without random other stuff
* under the covers it's direct interaction with the wsgi application
with regular plain ol http clients
* response validation that can be as simple or complex as you like
with json paths
* or even more complex if you want to write your own response
handlers[5]
* It's pretty easy to write (and correct if you get it wrong) these things.
That's a start at least.
Thanks for the good leading question.
[1] The placement api review[3] has a fairly straightforward
fixture[4] that has some but not all of the ideas that your fixture
would need. As Sergey correctly points out it needs to be cleaned up
now that it has a subclass.
[2] The test loader associates the gabbi yaml files with the wsgi
application that is being tested and produces standard python
unittest tests. There's an example in the placement api again:
https://review.openstack.org/#/c/293104/47/nova/tests/functional/gabbi/test_placement_api.py
[3] https://review.openstack.org/#/c/293104/
[4]
https://review.openstack.org/#/c/293104/47/nova/tests/functional/gabbi/fixtures.py
[5] https://gabbi.readthedocs.io/en/latest/handlers.html
--
Chris Dent (╯°□°)╯︵┻━┻ http://anticdent.org/
freenode: cdent tw: @anticdent__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
