Workshop about consumer-driven contract testing to improve testing within microservices architecture

1. Daria Golub, August 2020
Testing microservices.
Contract testing

2. Is it our job?
Part of being professional is
crafting a high-quality product

3. Motivation
Developer testing turns human
checking into machine checking,
thus, by definition, resulting in
testable software and freeing up
time for more interesting and
intellectually demanding testing
activities

4. Cost vs Quality
Martin Fowler. Is High Quality Software Worth the Cost?
https://martinfowler.com/articles/is-quality-worth-cost.html

5. cruft - the difference between the current code and
how it would ideally be.
• Neglecting internal quality leads to
rapid build up of cruft
• This cruft slows down feature
development
• Even a great team produces cruft,
but by keeping internal quality high,
is able to keep it under control
• High internal quality keeps cruft to a
minimum, allowing a team to add
features with less effort, time, and
cost.
High quality software is cheaper
to produce

6. Testing objectives
Approach “Testing to Critique”
• Will the user be delighted by the software?
• Is the scope reasonable?
• Has any function been forgotten?

7. Developer mindset Tester mindset

8. Testing objectives
Approach “Testing to Support”
• Support sustainable pace
• Support the team’s ability to work fast and without fear
• Provide confidence and fast feedback loop
• Provides quality feedback loop

9. Agile testing
Reactive to proactive
• Make sure that testing activities are taken into account during planning
• Testing should be included in estimations
• Help PO to specify desired functionality through defining test cases
• Pair programming/testing to avoid bias

10. Agile testing
Pair programming / testing. TDD
Writing tests
Writing
feature

11. Testing pyramid
Single function/method
Single service.
All collaborators subbed/mocked
Several services
Full coverage from UI

12. Unit tests
Best practices
• Calculate code coverage. Baseline to be defined by the team / for each
component
• PR should not bring down code coverage
• Every new/changed code should be covered with tests
• Cover not only happy flow, but also corner cases and alternative/exception
flows

13. Unit tests. Coverage

14. Service tests
Pros and Cons
run independently
give fast feedback
are stable
are easy to maintain
do not give us confidence to release.

15. Integration tests, E2E tests

16. Contract testing

17. Contract testing
is a technique for testing an integration point by checking each application
in isolation to ensure the messages it sends or receives conform to a
shared understanding that is documented in a "contract".

18. • Captures the interactions that are
exchanged between 2 service
• Stores them in a contract
• Each party verifies adherence to the
contract
Contract testing

19. Consumer driven contract testing. PACT
Pact is a code-first tool for testing HTTP and message integrations using contract
tests

20. Consumer side
During the consumer tests, each
request made to a Pact mock
provider is recorded into the
contract file, along with its
expected response.
How PACT works

21. Provider side
A Pact simulated consumer then
replays each request against the
real provider, and compares the
actual and expected responses.
How PACT works

22. Contract tests
run independently
give fast feedback
are stable
are easy to maintain
give confidence to release

23. What is PACT not good for?
• Testing APIs where the team maintaining the other side of the integration will not
also being using Pact
• Testing APIs where the consumers cannot be individually identified (eg. public
APIs).
• Testing providers where the consumer and provider teams do not have good
communication channels.
• Performance and load testing.
• Functional testing of the provider
• Testing "pass through" APIs, where the provider merely passes on the request
contents to a downstream service without validating them.

24. Matching. Best practices
Request matching
• Exact matching for the expectations for a request (as you are in control)
• Don’t use random or generated data (it can look like contract has changed)

25. Matching. Best practices
Response matching
• Response matching should be as loose as possible.
• Don’t test exact values!
• Use matching features like:
• Type matching
• Regular expressions

26. Implementation steps
Consumer
• Implement consumer test which will generate pact
• Publish pact to pact broker with consumer’s version and tag
Documentation:
https://docs.pact.io/

27. Implementation steps
Provider
• Implement provider test which will will get latest pact from pact broker
• Publish verification results with provider’s version and tag

28. Can I deploy?
• Add step to the CI/CD build which will check if latest version of Consumer /
Provider was verified
https://docs.pact.io/pact_broker/client_cli/readme
Docker image: pactfoundation/pact-cli:latest

29. Recommended literature
• Building Microservices by Sam Newman. Chapter 7 “Testing”
• Developer Testing by Alexander Tarlinder
• The Art of Unit Testing
• https://docs.pact.io/
• https://martinfowler.com/articles/is-quality-worth-cost.html