Unit Testing: Verifying Code's Smallest Parts

WHY IT EXISTS: As software grows, changing one part can unexpectedly break another. Manually re-testing everything after every change is slow, error-prone, and impossible at scale. We need a fast, reliable way to ensure the basic building blocks of our code still work correctly after being modified.

THE MENTAL MODEL: A unit test is like an electrician testing a single light switch. They don't turn on the power grid or check the city's power plant. They isolate the switch, connect a multimeter, and confirm it correctly opens and closes the circuit. The test is fast, focused, and tells you one thing: does this specific switch work in isolation?

HOW IT WORKS: Unit tests typically follow a pattern called Arrange-Act-Assert. First, you ARRANGE the test by setting up any necessary preconditions, like creating variables or objects. Second, you ACT by executing the single piece of code you want to test, usually by calling one function or method. Third, you ASSERT that the result is what you expected. Test frameworks like Jest or JUnit provide assertion helpers and a test runner to automate this process. To maintain isolation, external dependencies like databases or APIs are replaced with 'test doubles' like mocks or stubs.

WHEN TO USE IT: Use unit tests for business logic, algorithms, and data transformations. Any code with clear inputs and outputs is a perfect candidate. They should form the majority of your test suite because they are fast to run, stable, and provide immediate feedback. They are a cornerstone of Continuous Integration (CI) pipelines, acting as a safety net against introducing bugs.

WHEN NOT TO USE IT: Do not use unit tests to verify how multiple components work together; that is the job of integration tests. A unit test should never make a network call, access a filesystem, or interact with a real database. Attempting to do so makes tests slow, brittle, and difficult to maintain. Also, avoid testing trivial code like simple getters and setters that contain no logic.

ONE CANONICAL EXAMPLE: Imagine a function calculateDiscount(price, percentage). A unit test would not involve a real shopping cart or product database. One test case might look like this: first, ARRANGE by setting price = 100 and percentage = 20. Second, ACT by calling discountedPrice = calculateDiscount(100, 20). Third, ASSERT that discountedPrice is equal to 80. Another test would check an edge case, like a percentage of 0, asserting the price remains 100. These tests run in milliseconds and confirm the function's logic is sound.