Move daily emails into the blog page
This commit is contained in:
parent
be69398931
commit
1b8441608f
828 changed files with 9 additions and 196 deletions
24
source/_posts/2023-08-24.md
Normal file
24
source/_posts/2023-08-24.md
Normal file
|
@ -0,0 +1,24 @@
|
|||
---
|
||||
title: >
|
||||
Testing multiple implementations with contract tests
|
||||
pubDate: 2023-08-24
|
||||
permalink: >-
|
||||
daily/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]({{site.url}}/daily/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.
|
Loading…
Add table
Add a link
Reference in a new issue