Провайдер Pact-JVM тестирует разделение на конечную точку - PullRequest
0 голосов
/ 08 февраля 2019

Быстрый вопрос, возможно ли определить несколько классов на стороне провайдера для тестирования различных взаимодействий для конечной точки.Допустим, провайдер предоставляет API с двумя конечными точками: /api/v1/users и /api/v1/friends.Давайте также предположим, что у нас есть две потребительские службы, каждая из которых определяет договор пакта.Потребитель A использует как API провайдера, так и потребитель B нуждается только в /api/v1/users/:id.Вопрос в том, как определить тест поставщика для каждой конечной точки отдельно?

Запуск тестов в одном тесте означает, что нам нужно определить макеты для всех service / clients / repository / и т. Д.классы для каждого @State, используемые с обеих конечных точек - что становится действительно грязным и сложным в обслуживании.

Одно решение или, вернее, обходной путь, который я нашел, состоит в использовании значения @State в качестве целевой конечной точки и параметров длянести все остальное.Но любопытно узнать, пропускаю ли я что-нибудь из документации или есть ли лучшие практики для этого.

Та же проблема возникает, когда мы определяем несколько версий API, т.е. если мы вводим /api/v2/users.

Альтернативным вариантом будет вызов поставщика не после микросервиса, а после каждой конечной точки этого микросервиса.Таким образом, вместо двух пар consumerFoo -> providerFoo и consumerBar -> providerFoo у нас будет три пары consumerFoo -> providerFoo.users, consumerBar -> providerFoo.users, consumerBar -> providerFoo.friends.Это повышает уровень детализации матрицы зависимостей, но может также внести некоторую путаницу в нее.

...