Seven Practical Techniques for Writing Testable Code

In many cases, the ability to write unit tests is fundamentally a design issue; code written using Test‑Driven Development (TDD) often differs significantly from code written without it.

For ordinary programmers, producing easily testable code is the essential path to a high‑efficiency team.

For developers who have never written unit tests, creating useful tests usually means refactoring existing code—a process distinct from rewriting.

The key principle for writing testable code is simplicity, summarized by a single word: "less". This involves two main ideas: keeping functions short and limiting dependencies.

Below are seven practical "weapons" that help achieve this goal.

1. Keep functions short (no more than about 40 lines) and ensure they perform a single, well‑defined task. The exact line limit is flexible; the focus should be on low complexity that allows high test coverage.

2. Ensure each function does only one thing. Properly split responsibilities while considering granularity; for example, separating user‑ID lookup, data processing, and formatting into distinct functions.

3. Pass dependencies into functions via parameters. Instead of constructing a database object inside a function, inject it (preferably an abstract interface) as an argument.

4. Avoid passing complex structures as parameters. If a complex object is hard to construct for testing, pass only the necessary simple parameters or a minimal representation.

5. Depend on interfaces or abstractions rather than concrete implementations. This follows the Dependency Inversion Principle, allowing easy mocking of dependent components during testing.

6. Refactor large legacy classes or functions into smaller, testable units while keeping the original public interface unchanged.

7. Do not write unit tests for private functions directly. Private behavior should be exercised through public methods; if a private function cannot be covered, it may indicate low cohesion and suggest redesign. In cases where testing is unavoidable, language‑specific tricks (e.g., C++ friend, Go test files) can be used.

Compared with legacy code, new code is generally easier to test. To effectively add tests to existing codebases, refactoring is often the first step. Classic resources such as the second edition of "Refactoring" provide extensive techniques, but the seven practical methods above offer a quicker, hands‑on approach.