Open Stack

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