договорный потребитель HTTP-сообщений

У меня есть взаимосвязь между двумя компонентами / микросервисами, где компонент A отправляет события по протоколу HTTP компоненту B. В традиционном пакте HTTP-шаблона потребитель / поставщик A является потребителем B, поскольку A отправляет запрос, а B отвечает. Однако в этом случае B является реальным потребителем событий, которые предоставляет A.

Есть ли способ реализовать тесты потребителя / поставщика, чтобы тест потребителя мог быть написан на принимающей стороне (B), а не на отправляющей стороне?

Я видел, что были введены пакты сообщений, что звучит так, как будто их можно использовать в этом сценарии, но я не видел простых для понимания примеров того, как это реализовано, и можно ли его использовать в сочетании с HTTP, как в моем сценарии.

Я использую pact-jvm-junit.


http message-queue pact pact-java
person Joel Andersson    schedule 25.01.2017    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Вы обрисовали в общих чертах два смысла, в которых может использоваться термин потребитель / поставщик - пара HTTP-потребитель / поставщик и потребитель / поставщик самих данных.

Pact использует только HTTP смысл слов потребителя / поставщика, потому что вы не можете настроить макет в обратном порядке. Вы по-прежнему можете использовать Pact точно так же, как обычно - фактически, первый проект, в котором использовался Pact, был тем, в котором данные передавались от клиента javascript на внутренний сервер.

В любом случае большинство пар HTTP-потребитель / провайдер имеют двунаправленный поток данных. Это редкое приложение, предназначенное только для чтения. Вместо того, чтобы думать об этом как о том, «как я, как потребитель информации, хочу получить данные», подумайте об этом как о том, как я, как отправитель этих данных, хочу передать их получателю? ".

person Beth Skurrie    schedule 26.01.2017
comment
У меня изначально был такой подход. Моя проблема в том, что, на мой взгляд, это нарушает принцип контрактов, ориентированных на потребителя. Компонент А разработан другой командой и все еще находится в стадии разработки. Как потребитель событий A я хотел бы создать управляемый потребителем контракт в B, чтобы сообщить A, что я ожидаю от данных события, чтобы команда, разрабатывающая A, могла убедиться, что они соответствуют моим ожиданиям (B). A на самом деле не потребляет от B ничего, кроме ответа 204. Таким образом, реализуя его в этом направлении, мы потеряем аспект, управляемый тестированием / потребителем, и его преимущества. - person Joel Andersson; 26.01.2017
comment
В идеале я хотел бы какой-нибудь вариант MessagePact с расширенным протоколом Http. В качестве эксперимента я попытался реализовать свои тесты, используя вместо этого MessagePact, и это возможно, хотя я могу проверить только часть (тело) сообщения и потерял бы специфические для HTTP части пакта и проверки того же самого. - person Joel Andersson; 26.01.2017
comment
Да, у вас там сложный сценарий. Я не уверен, что Pact может вам сильно помочь. Первый сервис, о котором я упоминал, для которого использовался Pact, разработала одна и та же команда и для потребителя, и для поставщика, поэтому такой проблемы не было. - person Beth Skurrie; 30.01.2017