Consumer-Driven Contract tests (CDC tests) are a specialization of mock tests as described above. They work just like mock tests with the specialty that the interface contract is driven by the consumer and not, as one would expect naturally, by the provider.
6. New terminology: Producer and Consumer
User service
UI service
Consumer Producer
service that exposes a resource
7. End-to-end tests
User service
Test client
The most natural approach to testing API is end-to-end testing. In
end-to-end tests (E2E tests), real servers or containers are set up so
all other services they require as dependencies, such as databases
are available in a production-like runtime environment.
To execute our integration tests, the test client is calls the Service and
the test asserts (again in the UI) if the results meet the expectations
defined.
UI
8. New requirement about user name comes
User service
{
"id": 1,
"name": "James",
"age": 24,
"firstName": "James",
"secondName": "May"
}
9. New requirement about user name comes
User service
Test client UI
Refactored and test here
Fix tests here
18. Mock
In a mock test, we no longer set up
a whole runtime environment, but
run isolated tests between the
consumer and a mock provider and
between a mock consumer and the
real provider
19. Consumer-Driven Contract Tests
Consumer-Driven Contract
tests (CDC tests) are a
specialization of mock tests as
described above. They work
just like mock tests with the
specialty that the interface
contract is driven by the
consumer and not, as one
would expect naturally, by the
provider. This provides some
interesting advantages we will
come to later
20. Contracts
User service
Age validation UI New Service
{
"id": 1,
"name": "James",
"age": 24
}
{
"id": 1,
"name": "James",
"age": 24
}
{
"id": 1,
"name": "James",
"age": 24,
"firstName": "James",
"secondName": "May"
}
Consumers
Producer
Contract Contract Contract
By receiving contract test suites from all
consumers of a service, it is possible to
make changes to that service safe in the
knowledge that consumers won't be
impacted
21. E2E vs Mock vs Consumer-driven contract
● Isolation
● Complexity
● Test Data Setup
● Testing Data Semantics
● Feedback Time
● Stability
● Reveal Unused Interfaces
● Well-Fittedness
22. Isolation
isolated tests are easy to
execute and their results are
easy to interpret, thus we
should rely on them as long as
it’s possible.
E2E Mock CDC
Isolation
23. Complexity: For an E2E runtime
environment, we
have to deploy
containers running
your services, their
databases and any
other dependencies
they might have,
each in a specified
versions
E2E Mock CDC
Complexity
24. Test Data Setup:
Test data is always an issue when
implementing tests of any sort. In E2E tests
test data is especially troublesome since you
have potentially many services each with their
own database (see image in the previous
section). To set up a test environment for those
E2E tests you have to provide each of those
databases with test data that match the
expectations of your tests.
E2E Mock CDC
Test data setup
25. Testing Data Semantics
The correct semantics of data
exchanged over an interface are,
naturally, important for the data to
be processed correctly. However,
mock tests usually only check the
syntax of the data, e.g. if a user
data is syntactically correct but not
if a user not exist .
E2E Mock CDC
Testing data semantics
26. Feedback Time
Another important issue in testing is the time it takes from starting
your tests until you get the results and can act on them by fixing a
bug or modifying a test. The shorter this feedback time, the more
productive you can be.
Due to their integrative nature, E2E tests usually have a rather long
feedback time. One cause for this is the time it takes to set up a
complete E2E runtime environment. The other cause is that once
you have set up that environment you probably won’t just run a
single test but rather a complete suite of tests, which tends to take
some time.
E2E Mock CDC
Feedback time
27. Stability
Unstable tests lead to dangerous mindsets like
“A couple tests failed, but 90% successfull tests
are OK, so let’s deploy to production.”.
E2E Mock CDC
Stability
28. Reveal Unused Interfaces
E2E Mock CDC
Reveal Unused Interfaces
The provider does not really
know which operations of its
API are used by which
consumer. This may lead to a
situation where an operation
of the API is not used by any
consumer.
29. Well-Fittedness
E2E Mock CDC
Well-Fittedness
A very similar issue is the
issue of well-fittedness of the
API operations for a certain
consumer. If a provider
dictates an API contract, it
may not fit certain use cases
of certain consumers
optimally. If the consumer
defines the contract, it may be
defined to fit its use case
better
