Spring-cloud-contract: Leave only code input triggers and output message type

[marcingrzejszczak]

Currently, we support 3 different combinations of messaging contracts (-> means a message is sent). Let's say that we store contracts on the producer side. Our producer is service called A.

• code input triggers an output message A -> B
• input message triggers an output message B -> A -> B
• input message gets swallowed - there's no output message B -> A

come to think of it the 2nd and 3rd scenario are actually a combination of the 1st one. Let's imagine that we have service A and B.

A -> B (case 1)
B -> A -> B (case 2). This actually is B -> A (case 1) and A -> B (case 1 again). So we should have a contract on A and B side.
B -> A (case 3) - case 3 is actually case 1. The contract should be on the B side, not the A side.

I think that we should remove these 2 combinations.

WDYT @jkubrynski @Fitzoh @mbogoevici @dsyer

[mogronalol]

From Gitter:

Andrew Morgan @mogronalol Jul 18 18:18
B -> A -> B
Not sure I get splitting this up:
On B side calling bMethod() will send a message M1 to A
On A side consuming message M1 will send a message to B
So on A side do you still not need to do consume and produce of a message in one contract?
Then when you consume the message on A side, that needs to be trigger by running the stubs generated on b side?
(I’ve not got to the stubs yet)

Marcin Grzejszczak @marcingrzejszczak Jul 18 18:19
actually you can still split it into 2 cases... B calls A (1st case) , A calls B (2nd case). You don't necessarily want to check the logic of a processor
you want to check that on B side that A can trigger a message that you understand
and on A side that B can trigger a message that you understand

Andrew Morgan @mogronalol Jul 18 18:22
I need to experiment with the consumer side. But would you want the stub of B to produce a message M1 to A? So then when you test A, you run the stubs, and it get’s the M1 message sent to it?
So then when you verify A does the right thing when it gets the message from the stub, what do you verify?
Because I don’t necessarily think it would be so bad that it verifies that it produces another message
(In addition to anything else that is verifiable)
But then I guess, that could be separate from the CDC?

Marcin Grzejszczak @marcingrzejszczak Jul 18 18:25
so let's assume that the flow looks like this. B sends a message to A with list of tickets to buy. Then A sends back the message to B with a list of bought tickets.
So IMO we can have 2 separate cases. A writes a contract for B of what the message should look like and A triggers that message in its integration tests. A then asserts that it can properly parse the incoming message with a list of tickets.
Then B writes a contract for a message that A would send. With a list of bought tickets. Then B writes integration tests to see if it can parse the result
does it make any sense? :stuck_out_tongue:

Andrew Morgan @mogronalol Jul 18 18:26
Yes
It depends how you want to test. Because your contract in B which sends the list of bough tickets needs to be trigger by something. So you could just trigger it by a method call.

Marcin Grzejszczak @marcingrzejszczak Jul 18 18:29
exactly
that would be the case
in both contracts you would trigger by method calls

Andrew Morgan @mogronalol Jul 18 18:29
However I think could also useful be useful to trigger it from consuming a message from the stub of A
So it’s probably more of a personal preference?

Marcin Grzejszczak @marcingrzejszczak Jul 18 18:31
But then we're testing an implementation imo
We could then test if a http request triggers a message
But we don't do that for a reason

Andrew Morgan @mogronalol Jul 18 18:34
If you see the system as a black box, you could argue a message input -> outputs a message
Refactoring aswell becomes more painful if you don’t treat it that way
On the other hand it might be beastly to wire the whole app together, but you could end up doing it once and sharing it across all tests
Also, maybe that verification doesn’t belong in the contract

Marcin Grzejszczak @marcingrzejszczak Jul 18 18:43
Contract testing is not about doing black box testing of your system isn't it?

Andrew Morgan @mogronalol Jul 18 18:44
No
But it depends on how you want to do it

Marcin Grzejszczak @marcingrzejszczak Jul 18 18:44
That's true
But I think we should promote good practices

Andrew Morgan @mogronalol Jul 18 18:45
All I’m saying is it’s a grey area, stub input triggers a contract output doesn’t seem that crazy.
Who knows, if you don’t have that test then maybe when you deploy, something breaks along the way
Because you didn’t do the whole slice

Marcin Grzejszczak @marcingrzejszczak Jul 18 18:56
I'd say that the whole slice is part of end to end. But If sat that I see more value in this scenario than scenario 3

[mogronalol]

Another use case I have is if you follow the request-reply pattern with messaging. In this case, you want to define a stub in the same way as you would a HTTP endpoint. So you would need to define an input and output message together in the contract.

[marcingrzejszczak]

It turns out that there are users who still want this feature. So I'll close this issue.

[marcingrzejszczak]

Scenario 3 seems to actually be just scenario 1 but from the consumer's perspective. Maybe it should be removed really?