Unit vs Integration vs E2E Testing

Unit tests
Unit test - verify that individual, isolated parts work as expected.
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.
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, which can save a lot of time.
Another nice thing about unit tests is that they always work, and they work fast. Unlike end-to-end tests that rely on external components, unit tests are not flaky. If I can build a project on my machine, I should be able to run its unit tests.
Unit tests allow developers to refactor and add new features with confidence. When a developer refactoring a complex project that has well-written unit tests, he runs them often, usually after every small change.
Integration tests
Integration test - verify that several units work together in harmony.
Integration tests have one major advantage over unit tests: they ensure that modules that work well in isolation, also play well together. Integration tests typically focus on a small number of modules and test their interactions.
The idea behind integration tests is to mock as little as possible. Could be mocked:
Network requests (using a mocked version of
window.fetch
)Components responsible for animation (because who wants to wait for that in your tests?)
End to End tests
End to End test - A helper robot that behaves like a user to click around the app and verify that it functions correctly. Sometimes called "functional testing" or e2e.
Typically these will run the entire application (both frontend and backend) and your test will interact with the app just like a typical user would
End-to-end tests are good at capturing certain kinds of bugs, but their biggest drawback is that they cannot pinpoint 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.
End-to-end tests would fail if some external component, like a database or a messaging queue, is not available or cannot be reached. And they can take a very long time to run.
Last updated
Was this helpful?