To answer your question
Is this correct understanding? Am I missing anything?
The mechanism of sharing API Contracts depends on the contract testing approach you choose.
Consumer Driven Contract Testing
Tools like Pact have a broker to facilitate the collaboration between your provider A and consumer B, C and D.
- Team B, C and D emulate A by setting up a mock server with Pact DSL and run their respective component tests which in turn exercises the mock and generates consumer contract
- This consumer contracts is then pushed to the pact broker as part of your consumer application's CI pipeline
- The provider application A has to now run these consumer contacts (those published by B, C and D to the pact broker) as tests and post the test results back to pact broker
- At this point each application (A, B, C and D) can ask the "Can I deploy?" question to the pact broker. Please refer to the Pact documentation.
Provider Driven Contract Testing
Spring Cloud Contract in the producer contract testing approach follows this technique.
- Team A defines Contact with Spring Cloud Contract DSL and runs the verifier to make sure it is adhering to the contract it defined. In the process it generates stub jar files that can emulate it.
- Team A now uploads these stubs to a artifact manager such as nexus, artifactory, etc.
- Teams B, C and D can now leverage the stub jars in their respecting component testing to emulate A. As long as B, C and D are able to work with this stub jar they can be confident that they will work with the real application A.
Bi-Directional Contract Testing
PactFlow supports this approach where both consumer and provider have their own contracts.
Contract Driven Development
Specmatic leverages API Specifications such as OpenAPI as the API Contract. (Disclosure: I am lead dev and CTO at Specmatic)
- Team A and Teams B, C and D can collaborate over the API Design and author the OpenAPI Specification
- The API Specification is maintained in source code repo and any changes are made through a pull request mechanism so that all stakeholders can participate
- Consumers and Providers can now refer to this OpenAPI Specification in the Git repo to independently build their respective applications in parallel.
Is there any rule how consumer tests should look like? Should it be a real application B, C, D that calls our service or rather it should be a test that simulate those applications?
Here is a writeup on "Anatomy of Component Test"
What are the tools supporting contract-based testing?
Here is a list of tools that I have worked with.