What is unit testing?

nit testing is a type of automated testing where developers check the smallest pieces of code (functions, methods, or classes) in isolation to confirm each behaves as expected. This guide is written for testers, not developers. You probably don’t write unit tests, but understanding what they do, and what they miss, changes where you spend your time.

At a glance

• Unit tests are automated checks written by developers for individual functions, methods, or classes
• They catch logic bugs early but don’t test user journeys, UI, or how features interact
• Testers benefit from unit tests without writing them: fewer broken builds and trivial bugs reach QA
• Chasing 100% coverage creates busywork; good teams focus unit tests on complex or risky logic
• Focus your manual testing on what unit tests can’t check: real user behavior, workflows, and usability

The rest of this post covers what unit testing does and doesn’t test, who writes unit tests, and how to make the most of them as a tester.

What unit testing tests (and what it doesn’t)

A unit test checks one small, very specific piece of logic in isolation and nothing more. Even the definition of a “unit” varies between teams; Martin Fowler notes that the common ground is tests that are low-level and focus on a small part of the system. For example, a developer might write a unit test to confirm that:

• A discount is calculated correctly
• An error is returned when required data is missing
• A validation rule behaves as expected

The test sets up some input, runs the code, and checks the output. If the result matches expectations, the test passes. If not, it fails. Because unit tests are tightly focused, failures are usually very precise. When a test breaks, developers can see exactly which part of the code is responsible, without stepping through unrelated features.

This early feedback is why IBM often positions unit testing as part of a shift-left approach – catching defects as early as possible, when fixes are faster and significantly cheaper than later in the lifecycle.

What unit testing does not do is test how features behave from a user’s point of view. It doesn’t validate workflows, layouts, usability, or whether a feature makes sense in context.

Who writes unit tests (and who doesn’t)

Generally speaking, unit tests are written and maintained by developers. They live alongside the code and usually run automatically as part of the development process.

Testers typically:

• Don’t write unit tests
• Don’t manage them in test case tools
• Don’t run them manually

And that’s because unit testing exists to protect the code, whereas testing exists to protect the product. How testers influence unit testing is indirect. If the same type of logic bug keeps appearing during testing, that’s often a sign a unit test could prevent it happening in the future. You don’t need to write the test, but spotting the pattern and raising the risk is valuable.

Why does unit testing matter if you’re not a developer?

Good unit testing changes the shape of testing work because it catches simple errors early, letting QA concentrate on the issues that really affect users. When unit tests are in place and kept up to date:

• Basic logic bugs are caught earlier
• Fewer broken builds reach testing
• Less time is spent logging obvious defects

Unit tests reduce the number of simple code-level bugs, which means testers can focus on:

• Realistic user behavior
• End-to-end workflows
• Edge cases across multiple features
• Clarity, usability, and intent

What does unit testing miss?

Unit testing checks code logic and nothing else; whole categories of problems sit outside its reach.

Unit tests do not:

• Verify that features work together
• Validate real user journeys
• Check layout, accessibility, or responsiveness
• Catch configuration or environment issues
• Replace exploratory or manual testing

A feature can pass every unit test and still be confusing, frustrating, or broken from a user’s point of view. That’s not a failure of unit testing; checking the product from a user’s point of view was never its job.

Unit testing vs other types of testing

Rather than thinking in terms of “unit testing vs manual testing”, it’s more useful to see testing as layered, with each type covering different risks.

Unit testing supports everything above it by keeping the foundations stable. It doesn’t replace other testing – it makes it more effective.

Common misconceptions about unit testing

You may have heard a few persistent and problematic myths about unit testing, so let’s clear them up.

“If we have unit tests, we don’t need manual testing.”

Not true. Unit tests confirm the code behaves as expected. Manual testing confirms the product behaves sensibly.

“Unit tests should cover everything.”

In practice, chasing 100% coverage often creates busywork. Experienced teams focus unit tests on logic that’s complex, risky, or business-critical.

“Unit testing slows development.”

Writing tests does take time upfront, but catching bugs early and providing a safety net for future changes saves time overall. Testers benefit because fewer trivial bugs reach QA.

How can testers make the most of unit testing?

Testers don’t need to write unit tests to benefit from them. What testers can do is:

• Notice recurring logic issues and flag them early
• Highlight high-risk areas where unit tests could help
• Avoid duplicating unit-level checks in manual test cases
• Focus effort on behavior, workflows, and real-world usage

If a problem can only be found by thinking like a user, unit tests won’t catch it – and that’s exactly where testers are essential.

Want more practical testing advice?

Subscribe to get straightforward tips on all things testing sent straight to your inbox.

If you liked this article, consider sharing