Providing examples

Examples refer to the "example" on an Open API specification, but they behave more like fixtures in the context of testing.

As a general rule, the more examples you provide, the more tests can be built. Examples are used in combination with the other configuration to determine possible requests.

There are two types of example: Regular, and Dynamic. Regular examples are static, and do not change between reports. Dynamic examples are populated at runtime using your API (or any public GET URL with a JSON response) as a reference.

To get you started, the wizard can optionally attempt to suggest examples based on your specification.

Requests built from examples are assumed to be accessible to the credentials provided.

Dynamic examples

Dynamic examples are populated by the plan before each test report starts.

They are populated by sending a GET request which plucks values from JSON responses using JSONPath.

If there is a problem with populating a dynamic example, the example will be treated as if nothing has been provided, and the report will continue.

When the request provides a lot of examples, they are limited based on the "Test Limit" configuration.

Create dynamic examples by clicking add_circle.

Dynamic examples: API and Static paths

Dynamic examples can be provided in two ways:

• From your API specification, in which case the credentials will be used to retrieve examples
• From any static URL, in which case only basic authentication can be used

From API spec	From static URL

When using a path from your specification, an authorized request will be built using credentials. Static URLs can only support BASIC authentication, but these URLs are stored as plaintext so this is not recommended.

Writing dynamic examples manually

If you are building examples outside the console, they can be provided manually using the format #[{path}[?{params}]:{jsonPath}],

{path}	Either relative to the base path, or absolute (to external URL). If needed, requests will authenticate using supplied credentials.
{params}	Optional. A query string after the path denotes the query and path parameters used to build the request
{jsonPath}	Used to parse "path" to retrieve examples from the response. Learn how to use jsonpath at jsonpath.com

The following examples demonstrate the features a dynamic example can be built with:

Example	Request	Authorization	Plucked
#[/resources:$..id]	{basePath}/relative	Using credentials	All attributes matching "id"
#[/resources/{id}?id=1&foo=bar:$.*.id]	{basePath}/1?foo=bar	Using credentials	The "id" attributes of the top-level resources
#[https://test.com:$.data[?(@.num_reports > 10)]..id]	https://user:pass@example.com/v2/seed-data/?type=active	None	All "id" attributes where "num_reports" value is greater than 10
#[https://user:pass@test.com/v2/data ?type=active:$.editableSuites..id]	https://user:pass@example.com/v2/seed-data/?type=active	Basic	All "id" attributes belonging "editableSuites"

Seeding examples at runtime

Some workflows may be so complicated that it may be easier to use your API to tell the plan what examples to use directly.

This way, you have full control over the examples provided to the test runner (It will still respect the test limits).

For example, GET /v2/seed-data can respond with the below JSON which can be used with JSON path.

{
  "myUserId": "usr_7sfdo8",,
  "otherUserIds": ["usr_1dst68", "usr_3ih2d9", "usr_df3u9s6"],
  "editableSuiteIds": ["sui_editable1", "sui_s"],
  "visibleSuiteIds": ["sui_visible"]
}

Splitting up examples

By default, the plan does not separately identify fields that share the same name. The description of each field can be used to further distinguish how the example is used.

Please be aware that by splitting a field by description, if the description in the specification changes it may affect the tests.

Toggle split fields using call_split or merge, where available.

petId will be shared by all requests	petId is used only if it matches the description