Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

new: basedOnRequest strategy implemented #130

Merged
merged 4 commits into from
Feb 25, 2022

Conversation

eliseeviam
Copy link

A new request strategy was implemented according to an issue Добавить в моки возможность давать ответ в зависимости от body/query запроса.
From my point of view, the alternative way seems more explicit than extending the sequence strategy.

The point of this strategy is to provide the ability to send multiple parallel requests with the same path to an exact one service. Each request could be unique or similar.

For example, there is no way to mock these requests called in parallel:

/process?key=value1
/process?key=value2&opt_key

@Alexey19
Copy link
Contributor

Alexey19 commented Feb 13, 2022

Ну честно сказать не очень очевидный синтаксис. Я бы предпочел иметь что-то вроде

basedOnBodyFieldValue
basedOnQueryParamValue
basedOnHeaderValue

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

@eliseeviam
Copy link
Author

Хочу объяснить решаемую проблему и возможно найдется концептуально верное решение.

В процессе обработки запроса может происходить несколько запросов к одной и той же ручке, но с различными параметрами(телом, хидерами, etc) запроса. Также запросы могут быть отправлены параллельно.
Проблема в том, что ни одна из существующих стратегий не позволяет замокать такое поведение.
Из наиболее близких это uriVary, которой можно замокать только один запрос в нужным path, или sequence, которая позволяет замокать несколько запросов, но требовательна к порядку исполнения, который при параллельном вызове гарантировать нельзя.

Новая стратегия убирает ограничение уникальности с path и позволяет объявлять нескольно моков для одного и того же path.

requestConstraints я понимаю как способ проверить, что параметры запроса были сформированы ожидаемым образом. Что также соблюдается. Если ни один из запросов не удовлетворил requestConstraints, то тест будет провален.

if len(requestConstraints) > 0 {
requestDump, err := httputil.DumpRequest(r, true)
if err != nil {
fmt.Printf("Gonkey internal error: %s\n", err)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Единственное что мне тут не нравится, это вот этот принт ошибки, кажется стоит его добавить в виде

if err != nil {
    requestDump = []byte(`failed to dump request`)
}

надеюсь ничего с типами не напутал.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Спасибо! Поправил.
Заодно добавил возврат всех диффов верификации для запроса, для которого не нашлось мока.

@Cdayz Cdayz added enhancement New feature or request minor release as minor labels Feb 21, 2022
@Cdayz Cdayz merged commit 56e0afd into lamoda:master Feb 25, 2022
@github-actions
Copy link

🚀 PR was released in v1.14.0 🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request minor release as minor released
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants