Comments (7)
Саму задачу я бы разбил на несколько последовательных:
1 .Переменные описываются в самом файле с тестом:
- name: "my_request"
# ...
variables:
tag: "test_tag_name"
project: "my_project"
request: "tag={{tag}}"
Конкретно в этом пункте я сомневаюсь, может он и не нужен. Но следующие важны, и этот пункт может стать отправным для них (к примеру, описанные таким образом переменные могут заполняться результатом запроса, см. пункт 3)
2. Переменные берутся из env-файла (которые уточняется либо при запуске тестов, как параметр, либо в описании теста)
3. Значение переменной берётся из результатов одного из предыдущих запросов.
from gonkey.
В целом, мне нравится.
Синтаксис, когда в тело запроса или ответа подставляется значение вместо плейсхолдера, согласуется с существующем функционалом с кейсами:
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
Тут обязательно нужно продолжить этот синтаксис, который уже есть, не придумывать еще один, а то все сойдут с ума.
Первый пункт нравится, он годится как доказательство концепции. Советую начать с него.
Второй пункт нравится.
Третий пункт давно "витал в воздухе", но у меня нет идей, как синтаксически оформить запись переменной выдержками из результатов запроса. То есть, если у тебя есть какие-то идеи, то предлагай, без ясности в этом вопросе за третий пункт браться рано.
from gonkey.
Первый пункт нравится, он годится как доказательство концепции. Советую начать с него.
Я и хотел действовать в том порядке, в котором идут пункты :)
Но тут есть проблемка - в текущей структуре тестов нет возможности описать описать переменные, которые были бы общими для нескольких тестов, поскольку на верхнем уровне 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 }}
from gonkey.
Первый пункт готов и смержен, второй в процессе.
from gonkey.
Второй пункт тоже готов
from gonkey.
Все пункты реализованы, чуть позже опишу новый функционал в README
from gonkey.
Описание тоже готово
from gonkey.
Related Issues (20)
- Тестирование Prometheus метрик
- Использование фикстур вне теста HOT 1
- Начиная с релиза 1.18.2 не может быть создан Allure-отчет HOT 1
- Рефакторинг модуля с фикстурами и добавление возможности использовать переменные HOT 1
- Одновременная поддержка redis и postgres HOT 3
- Сделать путь до фейлящегося теста кликабельным HOT 9
- Оборачивать каждый тест в сабтесты HOT 3
- Add comparison params into request constraits/Добавить comparison params в request constraits HOT 1
- Добавить поддержку переменных теста в фикстуры HOT 2
- Добавить возможность объявнять кастомные функции HOT 1
- Fatal when test has status "broken" HOT 1
- Возможность использования динамических переменных
- Focus test status stopped to work HOT 1
- Реализовать механизм транзакций commit/rollback для фикстур HOT 1
- Реализовать автоматическую генерацию структуры папок и файлов при инициализации gonkey
- Параметризировать assert Response headers
- Изменение подхода работы с ContentType и поддержка application/x-www-form-urlencoded
- Fatal when set status skipped or broken HOT 3
- Добавление поддержки MongoDB в фикстурах
- Как протестировать получение файла? HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gonkey.