Writing Descriptive Test Method Names and Focusing on Public API

Test method names should convey the behavior under test rather than the specific implementation, because a descriptive name lets developers understand the purpose of a test without reading the entire test code.

When a test case is named ambiguously (e.g., invalidLogin), you must read all the code to discover the expected outcome; a clear name such as shouldLockOutUserAfterThreeInvalidLoginAttempts instantly reveals the behavior being verified.

Descriptive names bring several advantages: they make it easy to locate all possible behaviors of a class, aid code‑review by quickly showing which scenarios are covered, encourage splitting different behaviors into separate tests, and prevent hidden assumptions about what a test is actually checking.

A common naming pattern is to write the test name as a sentence that includes the keyword should, for example shouldLockOutUserAfterThreeInvalidLoginAttempts. Regardless of the pattern, the name should contain both the test scenario and the expected result.

The article also argues that tests should target the public API rather than internal implementation details. If a class is only used by a single public API (e.g., UserInfoService), testing the API may indirectly cover the class, making direct tests of the implementation unnecessary unless the class is complex or hard to reach through the API.

Implementation‑detail classes should have limited visibility (e.g., package‑private in Java) to reinforce the principle of testing through the public API, reducing coupling and maintenance overhead when signatures change.