OpenSearch/rest-api-spec/test/README.asciidoc

163 lines
4.6 KiB
Plaintext
Raw Normal View History

Test Suite:
===========
2013-06-28 11:42:00 -04:00
The tests in each YAML file should be run in order as a single set of dependent tests.
Before each file, the test cluster should be "reset" (eg deleting indices etc),
the `response` var and the `stash` should be cleared (see below).
Dot notation:
-------------
2013-06-28 11:42:00 -04:00
Dot notation is used for (1) method calls and (2) hierarchical data structures. For
instance, a method call like `cluster.health` would do the equivalent of:
2013-06-28 11:42:00 -04:00
client.cluster.health(...params...)
A test against `_tokens.1.token` would examine the `token` key, in the second element
of the `tokens` array, inside the `response` var (see below):
2013-06-28 11:42:00 -04:00
$val = $response->{tokens}[1]{token} # Perl syntax roolz!
If one of the levels (eg `tokens`) does not exist, it should return an undefined value.
If no field name is given (ie the empty string) then return the current
$val -- used for testing the whole response body.
Use \. to specify paths that actually contain '.' in the key name, for example
in the `indices.get_settings` API.
2013-06-28 11:42:00 -04:00
Skipping tests:
---------------
If tests should be skipped on particular versions of Elasticsearch, the
first entry in the list of tests should be called `skip`, and contain
the range of versions to be skipped, and the reason why the tests are
skipped. For instance:
2013-07-02 05:28:50 -04:00
....
2013-06-28 11:42:00 -04:00
"Parent":
- skip:
version: "0 - 0.90.2"
reason: Delete ignores the parent param
- do:
... test definitions ...
2013-07-02 05:28:50 -04:00
....
2013-06-28 11:42:00 -04:00
All tests in the file should be skipped if: `min <= current <= max`.
The `version` range should always have an upper bound. Versions should
either have each version part compared numerically, or should be converted
to a string with sufficient digits to allow string comparison, eg
0.90.2 -> 000-090-002
Snapshot versions and versions of the form `1.0.0.Beta1` can be treated
as the rounded down version, eg `1.0.0`.
Required operators:
-------------------
=== `do`
The `do` operator calls a method on the client. For instance:
2013-07-02 05:28:50 -04:00
....
2013-06-28 11:42:00 -04:00
- do:
cluster.health:
level: shards
2013-07-02 05:28:50 -04:00
....
2013-06-28 11:42:00 -04:00
The response from the `do` operator should be stored in the `response` var, which
is reset (1) at the beginning of a file or (2) on the next `do`.
2013-06-28 11:42:00 -04:00
If the arguments to `do` include `catch`, then we are expecting an error, which should
be caught and tested. For instance:
2013-07-02 05:28:50 -04:00
....
2013-06-28 11:42:00 -04:00
- do:
catch: missing
get:
index: test
type: test
id: 1
2013-07-02 05:28:50 -04:00
....
The argument to `catch` can be any of:
2013-07-02 05:28:50 -04:00
[horizontal]
2013-06-28 11:42:00 -04:00
`missing`:: a 404 response from ES
2013-07-23 13:20:40 -04:00
`conflict`:: a 409 response from ES
`request`:: a generic error response from ES
`param`:: a client-side error indicating an unknown parameter has been passed
to the method
`/foo bar/`:: the text of the error message matches this regular expression
If `catch` is specified, then the `response` var must be cleared, and the test
should fail if no error is thrown.
=== `set`
For some tests, it is necessary to extract a value from the previous `response`, in
2013-06-28 11:42:00 -04:00
order to reuse it in a subsequent `do` and other tests. For instance, when
testing indexing a document without a specified ID:
2013-07-02 05:28:50 -04:00
....
2013-06-28 11:42:00 -04:00
- do:
index:
index: test
type: test
- set: { _id: id } # stash the value of `response._id` as `id`
- do:
get:
index: test
type: test
id: $id # replace `$id` with the stashed value
- match: { _id: $id } # the returned `response._id` matches the stashed `id`
2013-07-02 05:28:50 -04:00
....
The stash should be reset at the beginning of each test file.
=== `is_true`
2013-06-28 11:42:00 -04:00
The specified key exists and has a true value (ie not `0`, `false`, `undefined`, `null`
or the empty string), eg:
2013-07-02 05:28:50 -04:00
....
- is_true: fields._parent # the _parent key exists in the fields hash and is "true"
2013-07-02 05:28:50 -04:00
....
=== `is_false`
2013-06-28 11:42:00 -04:00
The specified key doesn't exist or has a false value (ie `0`, `false`, `undefined`,
`null` or the empty string), eg:
2013-07-02 05:28:50 -04:00
....
- is_false: fields._source # the _source key doesn't exist in the fields hash or is "false"
....
=== `match`
2013-06-28 11:42:00 -04:00
Used to compare two variables (could be scalars, arrays or hashes). The two variables
should be identical, eg:
2013-07-02 05:28:50 -04:00
....
- match: { _source: { foo: bar }}
....
=== `lt` and `gt`
Compares two numeric values, eg:
2013-07-02 05:28:50 -04:00
....
2013-06-28 11:42:00 -04:00
- lt: { fields._ttl: 10000 } # the `_ttl` value is less than 10,000
2013-07-02 05:28:50 -04:00
....
=== `length`
This depends on the datatype of the value being examined, eg:
2013-07-02 05:28:50 -04:00
....
2013-06-28 11:42:00 -04:00
- length: { _id: 22 } # the `_id` string is 22 chars long
- length: { _tokens: 3 } # the `_tokens` array has 3 elements
- length: { _source: 5 } # the `_source` hash has 5 keys
2013-07-02 05:28:50 -04:00
....