Files
podman/test/apiv2/README.md
Ed Santiago 258749e43d apiv2 tests: finally fix POST as originally intended
When I originally wrote this code I had no idea what POST
would look like so I did a sloppy job, deferring making it
usable. Now that we have some real-world examples in place,
I have a better understanding of what params look like and
how to make tests more readable/maintainable. (Deferring isn't
always bad: one of my early ideas was to separate params using
commas; that would've been a disaster because some JSON values,
such as arrays, include commas).

This commit implements a better way of dealing with POST:

  * The main concept is still 'key=value'
    * When value is a JSON object (dictionary, array), it
      can be quoted.
    * Multiple params are simply separated by spaces.
      The 3-digit HTTP code is a prominent, readable separator
      between POST params and expected results. The parsing
      code is a little uglier, but test developers need
      never see that. The important thing is that writing
      tests is now easier.
  * POST params can be empty (this removes the need for a
    useless '')

I snuck in one unrelated change: one of the newly-added
tests, .NetworkSettings, was failing when run rootless
(which is how I test on my setup). I made it conditional.

Signed-off-by: Ed Santiago <santiago@redhat.com>
2021-03-10 05:24:44 -07:00

69 lines
2.7 KiB
Markdown

API v2 tests
============
This directory contains tests for the podman version 2 API (HTTP).
Tests themselves are in files of the form 'NN-NAME.at' where NN is a
two-digit number, NAME is a descriptive name, and '.at' is just
an extension I picked.
Running Tests
=============
The main test runner is `test-apiv2`. Usage is:
$ sudo ./test-apiv2 [NAME [...]]
...where NAME is one or more optional test names, e.g. 'image' or 'pod'
or both. By default, `test-apiv2` will invoke all `*.at` tests.
`test-apiv2` connects to *localhost only* and *via TCP*. There is
no support here for remote hosts or for UNIX sockets. This is a
framework for testing the API, not all possible protocols.
`test-apiv2` will start the service if it isn't already running.
Writing Tests
=============
The main test function is `t`. It runs `curl` against the server,
with POST parameters if present, and compares return status and
(optionally) string results from the server:
t GET /_ping 200 OK
^^^ ^^^^^^ ^^^ ^^
| | | +--- expected string result
| | +------- expected return code
| +-------------- endpoint to access
+------------------ method (GET, POST, DELETE, HEAD)
t POST libpod/volumes/create name=foo 201 .ID~[0-9a-f]\\{12\\}
^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^ ^^^ ^^^^^^^^^^^^^^^^^^^^
| | | JSON '.ID': expect 12-char hex
| | +-- expected code
| +----------- POST params
+--------------------------------- note the missing slash
Notes:
* If the endpoint has a leading slash (`/_ping`), `t` leaves it unchanged.
If there's no leading slash, `t` prepends `/v1.40`. This is a simple
convenience for simplicity of writing tests.
* When method is POST, the argument(s) after the endpoint may be a series
of POST parameters in the form 'key=value', separated by spaces:
t POST myentrypoint 200 ! no params
t POST myentrypoint id=$id 200 ! just one
t POST myentrypoint id=$id filter='{"foo":"bar"}' 200 ! two, with json
t POST myentrypoint name=$name badparam='["foo","bar"]' 500 ! etc...
`t` will convert the param list to JSON form for passing to the server.
A numeric status code terminates processing of POST parameters.
* The final arguments are one or more expected string results. If an
argument starts with a dot, `t` will invoke `jq` on the output to
fetch that field, and will compare it to the right-hand side of
the argument. If the separator is `=` (equals), `t` will require
an exact match; if `~` (tilde), `t` will use `expr` to compare.