Переменные в описании теста

[JustSkiv]

Очень нехватает возможности использования переменных в файле описания теста.

Например:

- name: "my_request"
  # ...
  request: "tag={{test_tag}}"

Для чего это требуется:

• Выносить из тестов в env-файл приватную информацию; Например: jwt, параметры доступа и т.п.)
• Выносить в общую переменную дублирующуюся информацию; Например: часто встречающиеся значения параметров (tag=test и т.п.)
• Возможность использования результатов предыдущего запроса; Например: можно будет запрос '/get_last_post_id', получив в ответе ID поста, протестировать следующий: '/get_post_info?id={{last_post_id}}'

Отдельно про env-файлы:
Это очень удобно для переключения контекста тестирования: мы можем тестировать API на продакшене, на стэйдже / тестовых серверах, на локальном сервере. Для всех этих случаев часто хочется иметь набор разных значений параметров для запросов.

В целом, все вышеописанное я не выдумал, а встречал в проектах, в чем-то аналогичных Gonkey. К примеру, у JetBrains есть нечто подобное: https://www.jetbrains.com/help/idea/http-client-in-product-code-editor.html#using_request_vars
Если не ошибаюсь, у Postman тоже.

Я понимаю, что задача не самая простая, и я готов взяться за её реализацию. Если даёте зеленый свет, я сначала согласую с вами пимерный план действий (как именно вышеописанное будет реализовано), что бы не было разнагласий по коду, и лишь потом приступлю к работе.
Данный функционал мне очень нужен в текущих проектах, поэтому работа не затянется до бесконечности и не будет заброшена.

Возможно также, что все это уже есть в том или ином виде, и я просто проглядел. Если так, прошу подсказать мне, в какую сторону смотреть.

[JustSkiv]

Саму задачу я бы разбил на несколько последовательных:

1 .Переменные описываются в самом файле с тестом:

- name: "my_request"
  # ...
  variables:
    tag: "test_tag_name"
    project: "my_project"
  request: "tag={{tag}}"

Конкретно в этом пункте я сомневаюсь, может он и не нужен. Но следующие важны, и этот пункт может стать отправным для них (к примеру, описанные таким образом переменные могут заполняться результатом запроса, см. пункт 3)

2. Переменные берутся из env-файла (которые уточняется либо при запуске тестов, как параметр, либо в описании теста)

3. Значение переменной берётся из результатов одного из предыдущих запросов.

[luza]

В целом, мне нравится.

Синтаксис, когда в тело запроса или ответа подставляется значение вместо плейсхолдера, согласуется с существующем функционалом с кейсами:

  response:
    200: |
      {
        "id": "550e8400-e29b-41d4-a716-446655440000",
        "jsonrpc": "2.0",
        "result": {
          "user_id": {{ .userId }},
          "amount": {{ .amount }},
          "token": "$matchRegexp(^\w{16}$)"
        }
      }

  cases:
    - requestArgs:
        orderNr: ORDER0001
      responseArgs:
        200:
          userId: '0001'
          amount: 1000

    - requestArgs:
        orderNr: ORDER0002
      responseArgs:
        200:
          userId: '0001'
          amount: 72000

Тут обязательно нужно продолжить этот синтаксис, который уже есть, не придумывать еще один, а то все сойдут с ума.

Первый пункт нравится, он годится как доказательство концепции. Советую начать с него.

Второй пункт нравится.

Третий пункт давно "витал в воздухе", но у меня нет идей, как синтаксически оформить запись переменной выдержками из результатов запроса. То есть, если у тебя есть какие-то идеи, то предлагай, без ясности в этом вопросе за третий пункт браться рано.

[JustSkiv]

Первый пункт нравится, он годится как доказательство концепции. Советую начать с него.

Я и хотел действовать в том порядке, в котором идут пункты :)
Но тут есть проблемка - в текущей структуре тестов нет возможности описать описать переменные, которые были бы общими для нескольких тестов, поскольку на верхнем уровне yaml-файла уже сам список тестов. А без этого смысла в переменных чуть меньше.
Ты не думал о возможности описания каких-то параметров на уровень выше, чем сами тесты? Что-то вроде:

variables:
  key1: "value1"
  key2: "value2"
tests:
 - name: "first_test"
   method: "POST"
   ...
 - name: "second_test"
   method: "GET"
   ...

Конечно, оно негодно в плане обратной совместимости, но такой файл мог бы в себя инклудить в себя описание списка тестов (в нынешнем виде)
Но я боюсь, что это может сильно усложнить логику, а пользы принесет мало. Но, как минимум, общие переменные понадобятся для обмена данными между тестами (см. п.3).

То есть, если у тебя есть какие-то идеи, то предлагай, без ясности в этом вопросе за третий пункт браться рано

Думаю, синтаксис может быть похожим на проверку ответа (над нэймингом надо еще подумать, у меня с ним порой плохо):

# если в ответе plain text
- name: "get_last_post_id"
  ...
  variablesSet:
          200: {{ .id }}

# если в ответе JSON
- name: "get_last_post_info"
  variablesSet:
          200:
            id: {{ .id }}
            title: {{ .title }}

[JustSkiv]

Первый пункт готов и смержен, второй в процессе.

[JustSkiv]

Второй пункт тоже готов

[JustSkiv]

Все пункты реализованы, чуть позже опишу новый функционал в README

[JustSkiv]

Описание тоже готово