Conversation
This README outlines the proposal for a tutorial on contract testing using Pact and Docker. It details the tutorial's structure, intended learning outcomes, and relevance to DevOps practices.
github-actions
Bot
added
the
tutorial
Gabjea
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Assignment Proposal
Title
Contract Testing: Pact and the Pact Broker
Names and KTH ID
Deadline
Category
Description
We will create an executable Killercoda tutorial on contract testing between microservices
with Pact. Everything runs in Docker (two Python services, the Pact Broker and its database),
with a Git hook standing in for CI, so no accounts are needed.
A user service renames a JSON field: its own tests pass, but the order service that depends
on it breaks. The learner writes a consumer contract with Pact (using type matchers so the
provider can still evolve), verifies the real provider against it using provider states, and
publishes the results to the Pact Broker. They then verify two consumer versions against three
provider versions and explore the resulting compatibility matrix. Starting from what is
recorded as deployed in production, they use
can-i-deployto discover that the rename canonly be released safely in three steps (expand, migrate, contract), with a Git pre-push hook
blocking unsafe deployments. Each step has an automated check, and the tutorial ends with a
reflection on when contract testing is worth it and its limits.
Intended learning outcomes. The learner can explain why separate test suites miss
breaking API changes, write and verify a Pact contract, read the compatibility matrix, and
use
can-i-deployto decide a safe deployment order.Relevance
Contract testing lets teams deploy services independently: API
compatibility is checked in seconds in CI instead of in slow end-to-end environments, and
can-i-deployacts as an automated deployment gate.