# Unit, Integration and End-To-End Tests - Finding the Right Balance

DevFeed: [Unit, Integration and End-To-End Tests - Finding the Right Balance](<https://devfeed.tech/articles/unit-integration-and-end-to-end-tests-finding-the-right-balance-24956.md>)

Original publisher: [Read original article](<https://codeahoy.com/2016/07/05/unit-integration-and-end-to-end-tests-finding-the-right-balance/>)

Author: umer

Published: 2016-07-05T00:00:00Z

Content type: article

Language: en

Sources: [Code Ahoy - Articles](<https://devfeed.tech/sources/code-ahoy-articles.md>)

Topics: [Testing](<https://devfeed.tech/topics/testing.md>), [Unit testing](<https://devfeed.tech/topics/unit-testing.md>), [Mocking](<https://devfeed.tech/topics/mocking.md>), [Code](<https://devfeed.tech/topics/code.md>), [Back end](<https://devfeed.tech/topics/backend.md>)

Tags: [automated](<https://devfeed.tech/tags/automated.md>), [backend](<https://devfeed.tech/tags/backend.md>), [bugs](<https://devfeed.tech/tags/bugs.md>), [errors](<https://devfeed.tech/tags/errors.md>), [http](<https://devfeed.tech/tags/http.md>), [mocking](<https://devfeed.tech/tags/mocking.md>), [testing](<https://devfeed.tech/tags/testing.md>), [tests](<https://devfeed.tech/tags/tests.md>), [unit-testing](<https://devfeed.tech/tags/unit-testing.md>), [unit-tests](<https://devfeed.tech/tags/unit-tests.md>)

## AI overview

This article explains how backend teams can distinguish unit, integration, and end-to-end tests and choose a balanced mix. It argues that unit tests should target small units in isolation, use mocks for dependencies, and provide fast feedback, while end-to-end tests cover broader flows but are slower, more dependent on external components, and harder to diagnose when they fail.

## Source excerpt

This is something I have regrettably noticed in many backend projects that I have worked on. Developers write "unit tests" that in reality are 'end-to-end' tests. They test the entire flow of the application from start to the end. There is no isolation of units and the notion of the unit is the whole system, along with all of its external dependencies like databases, queues, caches, and other services. For a web server project, these tests start the server, initialize a HTTP client, make a HTTP request and check the response to make sure it has all the expected information. If so, the test is declared a success. By treating the whole system as a unit and not testing independent units in isolation and their interplay, we loose many benefits that unit and integration tests offer. Technically speaking, these developers aren't violating the definition or principles of unit testing. Unit testing is ill-defined. I don't claim to be an expert, but in my humble opinion: Unit testing should focus on testing small units (typically a Class or a complex algorithm). Units should be tested in isolation and independent of other units. This is typically achieved by mocking the dependencies. Unit tests should be fast. Usually shouldn't take more than a few seconds to provide feedback. Most projects benefit from having a balanced mix of various automated tests to capture different types of errors. The exact composition of the mix varies depending on the nature of the project, as we'll see later. End-to-end tests are good at capturing certain kinds of bugs, but their biggest drawback is that they cannot pin-point the root cause of failure. Anything in the entire flow could have contributed to the error. In large and complex systems, it's like finding a needle in the haystack: you'll find the root cause, but it will take time. Because unit tests focus on small modules that are tested independently, they can identify the lines of code that caused the failure with laser-sharp accuracy, w