25 lines
1.1 KiB
Markdown
25 lines
1.1 KiB
Markdown
|
---
|
||
|
|
title: >
|
||
|
|
Testing multiple implementations with contract tests
|
||
|
|
pubDate: 2023-08-24
|
||
|
|
permalink: >-
|
||
|
|
archive/2023/08/24/testing-multiple-implementations-with-contract-tests
|
||
|
|
tags:
|
||
|
|
- automated-testing
|
||
|
|
- test-driven-development
|
||
|
|
---
|
||
|
|
|
||
|
|
If you have multiple implementations of a service, as I [mentioned in yesterday's email](https://www.oliverdavies.uk/archive/2023/08/23/dont-use-third-party-services-directly), you need to ensure they all provide the same functionality.
|
||
|
|
|
||
|
|
You need to be able to run the same tests against each implementation and have them pass.
|
||
|
|
|
||
|
|
## How do you do this?
|
||
|
|
|
||
|
|
In PHP, I use a trait that contains the test methods and then have a test class for each implementation that uses the trait and sets up any test data.
|
||
|
|
|
||
|
|
Then, each test class will run the methods from the contract test trait and ensure they all provide the same behaviour, regardless of how it does so - whether it communicates with an API, uses an SDK, or returns fake values.
|
||
|
|
|
||
|
|
If one implementation doesn't return the same result as the others, its test will fail.
|
||
|
|
|
||
|
|
If you add a new implementation, you create a new test class, use the trait and get the tests to pass.
|