Next, let’s consider end-to-end, or acceptance, tests. These tests use actual dependencies whenever possible. They’re the final check that we haven’t broken vital functionality for our customers. End-to-end tests increase our confidence that significant issues are caught before going to production.

As a best practice, keep these tests coarse and only test the most likely success paths and a couple of common error paths. When it comes to these acceptance tests, the system is a black box. And validation on state changes or events happens at the perimeter of the system. To further simplify these tests, consider excluding the UI, and test a headless build of the system to reduce issues with complex interactions.

In microservices, the main difficulty here involves flaky or brittle tests. If a complete business function involves multiple microservices, small changes throughout the system can make the tests unreliable and prone to error—especially for asynchronous processes that spawn events and fire-and-forget interactions.Minimize the number of acceptance tests to the most likely scenarios to reduce flakiness.

https://www.opslevel.com/blog/ship-more-confidently-with-these-7-microservice-testing-strategies