Do You Really Need Unit Testing?

Unit testing is often considered an essential part of software development, but is it really necessary in all cases? With modern testing strategies evolving, many teams are shifting towards end-to-end (E2E) testing as their primary approach. In this article, we’ll explore whether unit tests are truly needed or if E2E tests alone can provide sufficient coverage.

Unit Tests vs. End-to-End Tests

Before diving into whether you need unit tests, let’s quickly define the difference:

• Unit Tests: Test individual functions or classes in isolation. They don’t rely on databases, APIs, or the frontend.
• End-to-End (E2E) Tests: Test the entire application as a user would, ensuring the frontend, backend, database, and integrations work together correctly.

Traditional best practices say unit tests should be the foundation of your test suite, but is that always the best approach?

Why Some Developers Skip Unit Tests

1. E2E Tests Cover the Entire Flow

Unlike unit tests, which check isolated functions, E2E tests validate the real user experience. If an E2E test passes, you can be confident that the entire system works together—not just individual parts.

For example, an E2E test for a login feature would:

• Simulate a real user entering their credentials.
• Ensure the backend correctly validates the user.
• Check that the correct response is sent to the frontend.
• Verify that the user is redirected to the correct page.

Unit tests would require separate tests for each layer, and they still wouldn’t guarantee that the pieces fit together correctly.

2. Less Time Spent on Writing & Maintaining Tests

One argument against E2E tests is that they are slow. While this is true, consider the full picture:

• Writing unit tests for both frontend and backend can take more time than writing a single E2E test.
• End-to-end tests can often be written in plain English using tools like Cypress or Playwright, making them easier to maintain.
• If your team runs E2E tests as part of the CI/CD pipeline, they can execute while a PR is being reviewed, eliminating concerns about slow execution.

In bigger projects and enterprises, where PRs need review from a tech lead or architect, the time needed for review is often longer than the test execution time. So, the slowness of E2E tests doesn’t matter in practice.

3. Better Real-World Coverage

A major downside of unit tests is that they don’t simulate real user behavior.

• A function might pass all unit tests but still break in production because of unexpected interactions with other components.
• CSS or UI bugs (e.g., z-index issues, hidden buttons) cannot be caught by unit tests.
• API changes might not trigger unit test failures, even though they break the frontend.

Since E2E tests replicate real user behavior, they can catch these issues before users do.

4. QAs Can Write E2E Tests Without Deep Programming Knowledge

Unlike unit tests, which require developers to write code, E2E tests can be written by Quality Assurance (QA) engineers without needing to understand complex programming.

• Tools like Cypress, Playwright, or Selenium allow QAs to write tests in a more human-readable format.
• This ensures that real-world user scenarios are covered more effectively.
• Developers can focus on writing code instead of maintaining unit tests.

In contrast, if only programmers write unit tests, they might miss real user edge cases that QAs are more likely to catch.

When You Might Still Need Unit Tests

Despite these advantages, unit tests still have their place, especially in the following situations:

• ✔ Complex Business Logic – If a function involves complex calculations or domain-specific logic, it’s useful to test it in isolation.
• ✔ Library or Package Development – If you’re building a reusable package, unit tests ensure reliability across different projects.
• ✔ Fast Feedback Loops – Unit tests execute faster than E2E tests, making them useful for catching bugs early in development.

However, if your application’s main concern is ensuring the frontend and backend work together correctly, E2E tests alone may be enough.

Final Verdict: Do You Need Unit Tests?

It depends on your project and team setup:

• ✔ For small teams or fast-moving startups → Skip unit tests, focus on E2E tests.
• ✔ For large-scale applications with complex logic → Use unit tests selectively where needed.
• ✔ For enterprises with dedicated QA teams → Rely on E2E tests since they better match real user behavior.

If your E2E test suite is robust and well-structured, you might never need unit tests at all. Instead of blindly following best practices, consider what works best for your team’s workflow and project needs.

What’s Your Take?

Do you still write unit tests, or have you switched to an E2E-first approach? Share your thoughts in the comments!