Unit Testing Explained

The foundational testing practice that verifies individual functions and methods work correctly in isolation, catching bugs before they reach production.

Unit Testing

Unit testing is the practice of testing individual functions, methods, or components in isolation to verify they produce correct outputs for given inputs, typically using automated test frameworks.

Explanation

Unit tests are the foundation of the testing pyramid. Each test exercises a single "unit" of code — a function, method, or class — in isolation from its dependencies (databases, APIs, file systems). Dependencies are replaced with mocks, stubs, or fakes to ensure tests are fast, deterministic, and focused on the logic under test. Good unit tests follow the AAA pattern: Arrange (set up test data and mocks), Act (call the function under test), Assert (verify the output). They should be fast (milliseconds per test), independent (no test depends on another), and repeatable (same result every run). A comprehensive unit test suite catches regressions instantly, documents expected behavior, and enables confident refactoring. Popular frameworks include Jest and Vitest for JavaScript/TypeScript, pytest for Python, JUnit for Java, and Go's built-in testing package.

Bookuvai Implementation

Bookuvai requires unit test coverage for all business logic in every project. Our CI/CD pipelines enforce minimum coverage thresholds (typically 80%) and fail builds when tests break. We use Jest/Vitest for frontend, pytest for Python backends, and JUnit for Java services.

Key Facts

  • Tests individual functions or methods in isolation from dependencies
  • Uses mocks and stubs to replace external dependencies
  • Should be fast, independent, and deterministic
  • Forms the base of the testing pyramid — most numerous and fastest
  • Catches regressions instantly and enables safe refactoring

Related Terms

Frequently Asked Questions

What is a good unit test coverage percentage?
Aim for 80% coverage of business logic as a baseline. 100% coverage is often counterproductive because it includes trivial code. Focus coverage on complex logic, edge cases, and code paths that handle errors or money.
What is the difference between mocks and stubs?
Stubs return predetermined data when called — they simulate dependencies. Mocks go further by also verifying how they were called (which methods, with what arguments, how many times). Use stubs when you care about output; use mocks when you care about interactions.
Should unit tests test private methods?
Generally no. Test private methods indirectly through the public interface. If a private method is complex enough to need direct testing, it may be a sign that it should be extracted into its own class or module with its own public interface.