The Testing Honeycomb is a visual metaphor for the granularity/scope of and amounts of tests to write for a microservices-based software system. It's an adaptation of the traditional [[Testing pyramid]] specifically for [[Testing microservices]]. ![[microservices-testing-honeycomb-2.png]] [^sp1] [^sp1]: [Testing of Microservices](https://engineering.atspotify.com/2018/01/11/testing-of-microservices/) — Andre Schaffer & Rickard Dybeck (Spotify Engineering) It asserts that we should focus primarily on *Integration* Tests, have a few *Implementation Detail* Tests and even fewer *Integrated* Tests (ideally none). ## Definitions - **Integrated test** — A test that will pass or fail based on the correctness of another system (including other microservices within the same overall system). Some signs of having Integrated Tests are: - We spin up other services in a local testing environment - We test against other services in a shared testing environment - Changes to your system breaks tests for other systems - **Integration test** — verifies the correctness of our service in a more isolated fashion than an integrated test while focusing on the interaction points and making them very explicit. - **Implementation detail test** — Implementation Detail Tests are for parts of the code that are naturally isolated and have an internal complexity of their own. They are synonymous with [[Unit testing]] but this term is preferred because [[Unit test as a term is not commonly understood]]. --- ## References [Integrated tests are a scam](https://blog.thecodewhisperer.com/permalink/integrated-tests-are-a-scam) by J.B. Rainsberger