-
Notifications
You must be signed in to change notification settings - Fork 55
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
Conversation
Ну честно сказать не очень очевидный синтаксис. Я бы предпочел иметь что-то вроде
где возвращать результат в зависимости от значения поля в запросе, значения ключа или значения заголовка соответственно. Совсем странно использовать для этого requestConstraints, который создан совсем для другого. |
Хочу объяснить решаемую проблему и возможно найдется концептуально верное решение. В процессе обработки запроса может происходить несколько запросов к одной и той же ручке, но с различными параметрами(телом, хидерами, etc) запроса. Также запросы могут быть отправлены параллельно. Новая стратегия убирает ограничение уникальности с path и позволяет объявлять нескольно моков для одного и того же path. requestConstraints я понимаю как способ проверить, что параметры запроса были сформированы ожидаемым образом. Что также соблюдается. Если ни один из запросов не удовлетворил requestConstraints, то тест будет провален. |
mocks/definition.go
Outdated
if len(requestConstraints) > 0 { | ||
requestDump, err := httputil.DumpRequest(r, true) | ||
if err != nil { | ||
fmt.Printf("Gonkey internal error: %s\n", err) |
There was a problem hiding this comment.
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`)
}
надеюсь ничего с типами не напутал.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Спасибо! Поправил.
Заодно добавил возврат всех диффов верификации для запроса, для которого не нашлось мока.
🚀 PR was released in |
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: