Quality
Quality is velocity. Each change should have automated tests and it's important to help team understand on how they can test their changes
Types of test:
unit
mutation
contract
integration
snapshot
shadow
end-to-end (e2e)
Comparison
Description
How fast tests can be executed
How stable is the test suite
How expensive is to spin up test environment
How many systems are included in test execution
Ability to measure the coverage
Unit
milliseconds
single
Mutation
seconds
single
Contract
seconds
single
Integration
minutes
many
Snapshot
Shadow
many
E2E
minutes / hours
many
Contract testing
Contract testing focuses on interactions between services. It's used to help to ensure that different systems are compatible with each other.
Consumers are the systems which requests the data from the Provider.
Provider is the system which respond with the data to Consumer.
Both sides agree on the format of the requests and the responses. The communication is described in form of a contract. All involved parties must follow the contract to prevent breaking changes.
Sample contract:
{
"consumer": {
"name": "OrderingService"
},
"provider": {
"name": "PaymentService"
},
"interactions": [
{
"description": "A request to process a payment",
"request": {
"method": "POST",
"path": "/api/payments",
"headers": {
"Content-Type": "application/json"
},
"body": {
"orderId": "abc123",
"amount": 100.00,
"currency": "USD",
"paymentMethod": "credit_card"
}
},
"response": {
"status": 200,
"headers": {
"Content-Type": "application/json"
},
"body": {
"transactionId": "txn789",
"status": "success",
"amount": 100.00,
"currency": "USD"
}
}
}
],
"metadata": {
"pactSpecification": {
"version": "2.0.0"
}
}
}During each change either from Consumer or Provider side there is a verification process which confirms that both parties still adhere to the contract.
Actual Consumer sends the request to a Mock Provider which verifies the request and returns the responses based on the contract.
Mock Consumer sends the request defined in a contract to Actual Provider and verifies the response against the contract.
The beauty of this process is that it removes a dependency between both of the systems and each one can be tested in a separation.
Contract testing is especially useful:
for systems with microservices architecture
for system developed by multiple teams
when you maintain the system with multiple clients
FAQ
How we measure coverage with contract tests?
How in contract test we can make sure that mock is up to date?
Is mock auto generated in contract test?
What is consumer driven contract test?
What is provider driven contract test?
For each type of the test, how to measure the coverage?
Last updated
Was this helpful?