# Software testing pyramid When testing software, especially from a [[blog/engineering/testing/test driven development]] perspective, it's often helpful to break up the types of tests that you want to run in terms of their overall utility as well as the cost to run them. As such, you can think of a pyramid composed of three sections: [[unit tests]] at the base, [[integration tests]] in the mid-section, and [[system tests]] (or end-to-end/E2E tests) at the top. ![[software-testing-pyramid.png]] And this pyramid works on a few different levels: 1. [[unit tests]] are at the bottom because there are more of them. You're testing a single piece of functionality here and shouldn't rely at all on anything external to the code (e.g., databases, networks, etc.). These are the most granular test you can write. 2. [[integration tests]] are in the center because they build on the core functionality of the application. These check how different pieces of your application work together, ensuring data flows correctly and components communicate reliably. Unlike unit tests, integration tests often use actual databases, APIs, files, etc. to make them more realistic. As a result, they're slower to run, and there are often fewer of them. 3. [[system tests]] simulate how a real user interacts with the whole application from the front end through to the back end and any external services. System tests are the most complete and realistic; they ensure your software delivers on key user journeys and behaves as expected in real-world scenarios. These are often the slowest to execute, and there are fewer of them than the above two test types.