Unit Testing vs End-to-End Testing: Which Should QA Engineers Focus On?

A recent Hacker News discussion challenged conventional testing wisdom: despite knowing that unit tests are supposed to be the foundation of good testing practices, why do many developers feel that companies focus on them too much when end-to-end tests "feel more useful and less brittle" in practice?

This reflects a common experience: the gap between what we're told works (the testing pyramid with 70% unit tests) and what actually feels valuable when shipping software.

This Is Actually a Good Problem to Have

The HackerNews poster's concern is valid, but it reveals something interesting: worrying about "too many unit tests" is usually a sign of a mature testing culture.

Most development teams we work with aren't struggling with unit test obsession - they're struggling to write unit tests at all. They're stuck asking "should we start with unit tests or E2E tests?" while shipping code with no automated testing.

Unit test "obsession" means you've already solved the hard problems:

• You have automated testing in your CI/CD pipeline
• Developers are writing tests as they code
• You have enough test coverage to catch regressions
• Your team values test quality

That's further than most teams ever get.

The Natural Evolution of Testing Maturity

Teams typically go through phases:

Phase 1: No testing - Everything is manual, bugs reach production regularly

Phase 2: Some unit tests - Cover basic functions, developers start testing as they code

Phase 3: Unit test adoption - Comprehensive coverage, testing becomes part of the development workflow

Phase 4: "Too many unit tests" - The concern from HackerNews - questioning if the balance is right

If you're in Phase 4, you're doing well. The solution isn't to abandon unit tests - it's to add targeted E2E tests for integration scenarios that unit tests can't cover.

Why Unit Tests First Makes Sense

E2E tests feel more valuable because they catch user-facing issues, but they come with costs:

Slower execution - E2E tests take minutes, unit tests take seconds Higher maintenance - Browser changes, UI updates, and API changes break E2E tests Harder debugging - When an E2E test fails, it's not always clear which component caused the issue

Unit tests create a foundation of fast, reliable feedback. Once you have that foundation, E2E tests become surgical tools for testing integration points rather than your primary safety net.

When Unit Tests Do Make Sense

Unit tests aren't worthless - they're just overused. They excel when:

You have complex business logic that can be tested in isolation without mocking half your application.

You're working with pure functions that have clear inputs and outputs.

You need fast feedback loops during development for algorithmic or computational code.

But if you find yourself writing more test setup code than actual test logic, or if your tests break every time you refactor, you're probably testing at the wrong level.

How GitAuto Changes the Unit Testing Equation

Here's where automated unit test generation becomes interesting: it removes the main downside of unit testing (the time investment) while keeping the benefits (fast feedback, regression detection).

When unit tests are generated automatically, you can have comprehensive coverage without slowing down development. This means you can focus your manual testing effort on the complex E2E scenarios where human judgment is actually needed.

The key insight: don't choose between unit and E2E tests based on ideology. Choose based on what actually breaks in your specific application, and use automation to make the less valuable tests cost nothing to maintain.

Source: Ask HN: Why focus on unit tests over end-to-end tests?