0

I have a relationship between two components/microservices where component A sends events by HTTP to component B. In a traditional pact HTTP consumer/provider pattern, A is the consumer of B since A is sending the request and B is responding. However, in this case, B is the real consumer of the events that A provides.

Is there a way of implementing the consumer/provider tests so that the consumer test can be written on the receiving side (B) rather than on the sending side?

I have seen that message pacts have been introduced which sounds like it could be used in this scenario but I haven't seen any easy to understand examples of how this is implemented and if it can be used in conjunction with HTTP like in my scenario.

I'm using pact-jvm-junit.

J_A_X
  • 12,857
  • 1
  • 25
  • 31
Joel Andersson
  • 239
  • 2
  • 7

1 Answers1

2

You've outlined to two senses in which the term consumer/provider can be used - the HTTP consumer/provider pair and the consumer/provider of the data itself.

Pact only uses the HTTP consumer/provider sense of the words, because you can't really set up the mock in reverse. You can still use Pact exactly the same way you would normally though - in fact, the first project that used Pact was one where the data flowed from the javascript client to the backend server.

Most HTTP consumer/provider pairs have bi-directional data flow anyway. It's a rare app that is read only. Rather than thinking of it as "how do I, as the consumer of the information, wish to receive the data", think of it as saying "how do I, as the sender of this data, wish to transfer it to the recipient?".

Beth Skurrie
  • 1,333
  • 7
  • 8
  • I had this approach initially. My problem is that it violates the principle of consumer driven contracts in my opinion. Component A is developed by another team and is still a work in progress. As the consumer of A's events I would like to create a consumer driven contract in B to tell A what I expect the event data to contain so that the team developing A can make sure they conform to my (B's) expectancies. A is not really consuming anything from B other than a 204 response. So implementing it in that direction we would loose the test driven/consumer driven aspect and it's benefits. – Joel Andersson Jan 26 '17 at 08:23
  • Ideally I would like some Http enhanced variant of the MessagePact. As an experiment I've tried to implement my tests using the MessagePact's instead and it is possible although I'm only able to validate the message part (body) and would loose the HTTP specific parts of the pact and the validations of the same. – Joel Andersson Jan 26 '17 at 08:35
  • Yeah, you're in a tricky scenario there. I'm not sure Pact can help you much. That first service that I mentioned that Pact was used for, the same team developed both the consumer and the provider, so there wasn't the same problem. – Beth Skurrie Jan 29 '17 at 23:04