Scenario
Given a contract1 from consumer1 to producer over an endpoint
When a contract2 from consumer2 to producer over the same endpoint is created with a more lenient response body
And producer:v2:stubs is produced
Then consumer1 is potentially inadvertently broken by using producer:latest:stubs
Example
contract1 (consumer1)
Contract.make {
request {
method 'GET'
url '/endpoint'
}
response {
status 200
body([
name : 'name'
description : 'description'
])
headers { contentType(applicationJson()) }
}
}
contract2 (consumer2)
Contract.make {
request {
method 'GET'
url '/endpoint'
}
response {
status 200
body([
name : 'name'
])
headers { contentType(applicationJson()) }
}
}
** It's all the same but the missing description field.
Description
When running consumer1 tests with the stubs generated from previous contracts, it might be that the chosen stub is based on contract2, hence violating consumer1 expectations.
Ideally, consumer1 shouldn't even know consumer2 even existed, and it definitely shouldn't be affected by consumer2's contracts.
Reviewing the documentation, packaging all contracts by producer is the proposed approach, but it's flawed by the aforementioned lack of isolation between consumers.
Am I missing something?
Options
Priority
I understand there is the priority attribute to help, but I don't think is meant for this purpose, as it requires consumers to go messing with each other's contracts. Also it requires the consumer to be aware of the existence of potential clashes.
Consumer self-declared identification
If the consumer was able to identify itself when performing the request (i.e. in a header), it could use that in the contract. But it would still require for the consumer to be aware that clashes are possible.
Package by producer+consumer not just producer
It would be possible to isolate consumers by producing different artifacts by the pair (producer, consumer) instead of just producer, but it feels kind of overkill and not documented, so future users might find themselves in the same spot we are now.
Is there any other option built-in SCC?
Should there be?
Scenario
Example
contract1 (consumer1)
contract2 (consumer2)
** It's all the same but the missing description field.
Description
When running consumer1 tests with the stubs generated from previous contracts, it might be that the chosen stub is based on contract2, hence violating consumer1 expectations.
Ideally, consumer1 shouldn't even know consumer2 even existed, and it definitely shouldn't be affected by consumer2's contracts.
Reviewing the documentation, packaging all contracts by producer is the proposed approach, but it's flawed by the aforementioned lack of isolation between consumers.
Am I missing something?
Options
Priority
I understand there is the priority attribute to help, but I don't think is meant for this purpose, as it requires consumers to go messing with each other's contracts. Also it requires the consumer to be aware of the existence of potential clashes.
Consumer self-declared identification
If the consumer was able to identify itself when performing the request (i.e. in a header), it could use that in the contract. But it would still require for the consumer to be aware that clashes are possible.
Package by producer+consumer not just producer
It would be possible to isolate consumers by producing different artifacts by the pair (producer, consumer) instead of just producer, but it feels kind of overkill and not documented, so future users might find themselves in the same spot we are now.
Is there any other option built-in SCC?
Should there be?