Consumer driven contract testing vs behavior testing

Question

I am not exactly able to understand how is consumer-driven contract testing different from behavior-driven testing? what is the pact server doing for consumer-driven contract testing that we have not been doing by specifying the expected behavior of the provider service in the consumer and verifying if the response from the provider matches the expectation in the consumer?

Answer 1

I did a quick search for the definition of "behaviour-driven testing" and couldn't find a good source. I'm going to assume that you mean "a test that uses both the real consumer and provider together at the same time to ensure that 1. the consumer and provider work correctly together and 2. that the provider is implemented correctly" (these seem to be the concerns you mentioned in your question). There are a few points that I think are relevant.

1. Contract testing (regardless of whether it is consumer driven or not) allows you to test each application in isolation. The testing approach you mentioned above does not (if I understand it correctly).
2. "specifying the expected behaviour of the provider service in the consumer and verifying if the response from the provider matches the expectation in the consumer" > This actually sounds like exactly what CDC is doing, except that the verification step happens in the provider tests, not the consumer tests.

There is a page that describes the difference between functional tests and contract tests here

There is some more information about what the role of each kind of test should be in the Pact docs here.

There is information on the advantages of contract testing here

Answer 2

Contract testing and Behavior-Driven testing have different intentions.

Contract tests helps to ensure communications between to components (services, system or whatever) is not broken. When you have confidence that contracts is not broken you can develop and test your systems independently in isolation. For them only matter format and scheme correctness of requests and responses.

Behaviour-Driven tests aims to check functionality of system from user-behavior perspective. Usually you make actions and then check side-effects. And if you have separate contract tests you can freely mock/stub external systems to reduce flakiness and tests execution time.

Of course it's possible to check all fields in response in behaviour-driven tests, but it becomes less readable (behavioural checks mixes with schema checks), in most cases such tests hard to share with other team (they couldn't simply run this tests to make sure that they didn't brake contracts) and your tests remains dependant from availability external system.