Testing Behavior, Not Methods: Ensuring Clear Cause and Effect in Unit Tests

This article, translated from the Google Testing Blog, argues that test cases should validate software behavior instead of being a one‑to‑one mirror of the method under test.

It debunks the misconception that each method requires a single test, noting that a method can exhibit many behaviors and a single behavior may involve multiple methods.

Illustrated with a poor example, the article shows a test that both displays a product name and sends a low‑balance email in one method, resulting in bloated, hard‑to‑maintain test code.

The author recommends using separate tests for separate behaviors, ensuring that each test’s cause and effect are immediately visible, which makes failures easier to diagnose.

Another issue highlighted is an assertion on key1 placed more than two hundred lines away from the code that modifies it, hiding the reason for the assertion and making the test hard to understand.

Proper tests should keep the cause (input) and effect (assertion) close together, following natural language reasoning: if the cause occurs, the effect follows.

Although this approach may increase the number of test cases, each test sets its own input and verifies its own expected output, leading to more readable code and lower maintenance costs.

Overall, focusing on behavior‑driven, isolated tests improves test resilience and code quality.