Adapter contract testing
How to test your integrations with external dependencies and reuse those same tests to build simulators.
The simulators allows you to test without any mocks in your whole codebase
Establish a contract with a read- only dependency • Use simulators to test the domain with con fi dence Road-book high level view Photo de Jesse Bowser sur Unsplash
• Driver role : Have the keyboard Responsible to translate ideas to code • Navigators role : Tells the driver what you want to be done • Switch roles often • If you have an idea : be a kind navigator Hands-on setup Photo de Halogen Condense sur Unsplash
of your chosen language 2. Follow README instruction : 1. Start mongo db locally docker run --rm -p 27017:27017 --name mongo_contract_testing -d mongo 2. Start race server locally docker run --rm -d -p8000:8000 --name snail-race-server mathieucans/snail-race-server:latest 3. Execute requirement test If you are done : help others! 🤝
a test against a database • Extract the contract test • Use contract test to write a simulator Road-book Step 1 Photo de Glenn Carstens-Peters sur Unsplash
MongoDb Test Mongo DB BetRepository BetRepositorySimulator BetRepository Simulator Test BetRepository Contract Inherit Inherit Setup only Setup only All tests are here ➡
Explore the endpoint with a unit test 2. Use the json response to create infrastructure types 3. Write a contract test that uses the desired port 4. Unit test the mapping (infra -> domain) with pure unit tests 2. Write simulator Roadbook Step 2
restructurings on the data from providers 👉 Allowing to build highly typed domain objects 2. Use the tests to run them on massive amounts of data 3. You’ve simpli fi ed the job for the domain and you can be certain the simpli fi cation is valid Tranformation Validation Normalisation Dirty DTO Clean Domain Object
• Use the simulators • Write a f….g test 😂 • Take time to appreciate: • domain language in tests • test brievety • fast feedback • con fi ence because we’re utterly close to the production behaviour and interaction Roadbook Step3
bet is done by providing • gambler name • the 3 numbers of snails on the podium The application lists the winners according to last race ran. To win a bet : • The podium match exactly the race result • The bet has been registered at least 3 seconds before the race timestamp • A bet is valid only for the next race
Mocks - James Shore • Architecture Hexagonale : gestion de la complexité logicielle et de la dette technique - Julien Topçu • Outside-In Diamond TDD - Thomas Pierrain
check if an email has been replied to It can be implemented through threads Need to expose this to the domain 1. Discovered how thread works through contract tests 2. Use these tests to write a simulator like gmail 3. Very productive and con fi dent in implementing the domain logic
been written to consume orange mails The application was tested with simulators Need to change end point used to read mails in the adapter (QOS issue) 1. Write the adapter with the new end point 2. Check the behavior still works as the old one and the simulator 3. Integrate the new end point safely without change neither domain code nor domain tests
particular for listing nested folders • There were around 15 methods on it • Having the fake made it very easy to implement a good caching system • As a result it was easy to implement both a persistent and an ephemeral caching system Storage OneDrive Slow
Problem: not really. Read-only but stable • Solution: keep the exact assertions • In retrospect: They changed sometimes, but not often. Our app Data.gouv
Heteregenous data • Solution: Try ingesting big amounts of data as a test • Result: We discovered rare problems in dev as opposed to production Our app Data.gouv Heteregenous data
has a chatty api with a native app. • Problem: complex and wrong mocking • Solution: build a simulator (without contract testing) • Gain: Reliable tests of the isolated js-app js app native app Complex interactions