gonkey

You can inherit data from one record to another across different files.

1. In the source file, assign a unique name to a record using the $name key.
2. In the target file, use the $extend key with that name to inherit the record's fields.
3. Ensure the target file includes the source file in its inherits list.

Constraints:

• Names assigned via $name must be unique across all loaded fixture files and must not collide with template names.
• Record inheritance ($extend for records) only works between different files. It is not supported within the same file.
• You cannot reference template fields using this method; you can only reference actual records.

# fixtures/post.yaml
tables:
  posts:
    - $name: regular_post
      title: Post title
      text: Some text

# fixtures/deleted_post.yaml
inherits:
  - post
tables:
  posts:
    - $extend: regular_post
      is_deleted: true

After HTTP requests, you can execute SQL SELECT queries to verify data changes. The query results are compared against an expected list of JSON objects.

Formats

• Recommended Format: Use dbChecks to allow multiple queries per test.
• Legacy Format: Use dbQuery and dbResponse directly in the test root (supports only one query).

Features

• Regexp Support: You can use $matchRegexp(pattern) within the dbResponse JSON strings to validate fields using regular expressions.
• Parameterization: Use {{ .var }} syntax in dbQuery and dbResponse. Provide values via dbQueryArgs and dbResponseArgs in the cases section. To override the entire expected response for a specific case, use dbResponseFull.
• Ignore Ordering: To avoid issues with ORDER BY requirements, set ignoreDbOrdering: true inside the comparisonParams section.

# Recommended format with multiple checks
- name: my test
  dbChecks:
    - dbQuery: "SELECT code, partner_id FROM mark_paid_schedule"
      dbResponse:
        - '{"code":"GIFT123456","partner_id":1}'

# Parameterized query and response
  dbQuery: "SELECT code FROM table WHERE id = '{{ .id }}'"
  dbResponse:
    - '{"code":"{{ .expected_code }}"}'
  cases:
    - dbQueryArgs:
        id: "123"
      dbResponseArgs:
        expected_code: "ABC"

# Ignoring result order
comparisonParams:
  ignoreDbOrdering: true

dbQuery: "SELECT id FROM users LIMIT 2"
dbResponse:
  - '{"id": 2}'
  - '{"id": 1}'

After an HTTP request, you can execute SQL SELECT queries to verify data changes in the database. The results are compared against an expected list of JSON objects.

There are two ways to define DB checks:

1. Legacy style: Using dbQuery and dbResponse directly at the test level.
2. Current style: Using dbChecks which allows running multiple queries per test case.

Query definition: dbQuery must be a SELECT statement that returns strings. Response definition: dbResponse is a list of JSON objects. You can use Regexp for matching values using the $matchRegexp syntax.

# Current recommended style for multiple queries
dbChecks:
  - dbQuery: >
      SELECT code, purchase_date, partner_id FROM mark_paid_schedule WHERE code = 'GIFT100000-000002'
    dbResponse:
      - '{"code":"GIFT100000-000002","purchase_date":"2330-02-02T13:15:11.912874","partner_id":1}'
      - '{"code":"$matchRegexp(GIFT([0-9]{6})-([0-9]{6}))","purchase_date":"2330-02-02T13:15:11.912874","partner_id":1}'

Test cases are defined in YAML files. A single scenario can include:

• name: Description of the test.
• method: HTTP method (e.g., GET, POST).
• path: The endpoint path.
• query: Query parameters (the leading ? is optional).
• headers: HTTP headers.
• cookies: Cookie values.
• fixtures: List of fixture names to load.
• request: The request body (supports template variables like {{ .var }}).
• response: Expected response status and body. Supports JSON or raw text.
• comparisonParams: Configuration for response comparison:
  • ignoreValues: boolean
  • ignoreArraysOrdering: boolean
  • disallowExtraFields: boolean
• cases: A list of specific input/output pairs for the scenario using requestArgs and responseArgs to populate templates.

- name: "Scenario Name"
  method: GET
  path: /api/resource
  fixtures:
    - my_fixture
  response:
    200: |
      {
        "status": "ok"
      }
  cases:
    - requestArgs:
        param: value
      responseArgs:
        200:
          field: result

Gonkey supports variables in various test fields using the {{ $variable_name }} syntax. This allows for dynamic test definitions. Supported fields include:

• method
• description
• path
• query
• headers
• request
• response
• dbQuery
• dbResponse
• body (for mocks)
• headers (for mocks)
• requestConstraints (for mocks)
• form (for multipart/form-data)

Variables can be assigned via several methods, with priorities following the order of assignment (Test description > Previous request results > Current request results > Mock captures > Environment variables).

- method: "{{ $method }}"
  description: "{{ $description }}"
  path: "/some/path/{{ $pathPart }}"
  query: "{{ $query }}"
  headers:
    header1: "{{ $header }}"
  request: '{"reqParam": "{{ $reqParam }}"}'
  response:
    200: "{{ $resp }}"
  mocks:
    server_mock:
      strategy: constant
      body: >
        {
          "message": "{{ $mockParam }}"
        }
      statusCode: 200
  dbQuery: >
    SELECT id, name FROM testing_tools WHERE id={{ $sqlQueryParam }}
  dbResponse:
    - '{"id": {{ $sqlResultParam }}, "name": "gonkey"}'