Integrations Testing
A common way to test APIs to to rely on curl or postman (or any similar tool) and send queries over the wire to the API. In this kind of tests, the API is expected to produce a result, which by definition means that the can can either be functional or business oriented.
Pros
- Fast and cheap to create
- Meaningful results
Cons
- Slow in CI
- High test data maintenance
Contract Testing
Contract testing does not replace functional testing. The primary goal of contract testing is to make sure that both the consumer and the producer have mathcings schemas to prevent integrations from breaking.
A sample request and response is used to generate the expected schema. This schema will be stored inside the broker. Tests will now run against the service and the service will communicate with the broker.
Most of this happens on the unit test level.
Pros
- Fast
Cons
- Initial investiment is high
- Tests can only be maintained by developers (unit test level)
- Ignores functionality
Consumer Driven Contract Testing (CDCT)
A mix of classic integration testing and contract testing exists: Consumer Driven Contract Tests. In such a case, when the consumer is called, the application will reach out to whatever producer service it is suppoed to connect to and a mock will respond using the producer’ schema response. If the consumer cannot read the producer’s response, the test fails.
Pros
- Fast and cheap to create, if OpenAPI docs are up to date
- Meaningful results
Cons
- Slow in CI
- If OpenAPI docs are not up to date, a lot of time will go to creation of mocks