https://www.youtube.com/watch?v=vkAfGHd7sZY
what is the confidence that we hope to get from this test and what is the understanding that we hope to get from this test suite
At 23 minutes he talks about contract testing.
"If my tests fake out WalrusService, how can I trust that GET /walruses still returns walruses"
At 23:30: why not test across service boundaries? Why not really call the walrus service?
At 23:41 Three step guide to making intra-service testing easy:
1) Start by not writing them
2) Continue to not write them
3) Already done... so easy!
At 24:22 The root question indicates a lack of trust. I don't trust the walrus service to give me the right (data).
At 24:39 default to trusting the services on which you depend (if they are internal services managed by another team within your organization).
talk-breaking-up-with-your-test-suite#contract-tests1
At 25:24 when trust isn't enough, I write contract tests.
The user is you
Test is written to represent your own interests in someone else's repo.
Your needs become part of that team's consumption suite.
If that test breaks, they know who to call. They have made a change that violates your expectations.
At 26:05: speedier feedback. Don't wait for a production release to know about breakages. Git push and early test failure is an easier conversation to have than that the production service broke.
At 26:35 other services will continue to work the way we need them to.
talk-breaking-up-with-your-test-suite#contract-tests1
redundant coverage increases cost-to-change