Why Proximity Matters in Automated Testing: From End‑to‑End to Unit Tests

Many people think that before any change, an end‑to‑end "smoke test" should cover the application, which sounds like a good idea.

However, the farther the test location is from the code being modified, the harder it is to write automated test cases that target specific logic.

In such cases, developers often have to repeatedly adjust input parameters in end‑to‑end tests and observe behavior to create usable automated tests, akin to trying to hit a small ground target from an airplane with a stone.

In reality, the closer the test is to the modification point, the easier testing becomes.

Unfortunately, many codebases lack modularity, which is the key to effective testing.

Traditional class‑level or function‑level modularization is now considered less important; instead, a "Service" is seen as an appropriately sized testing unit.

When we want to know how a piece of code runs and how many lines we need to write to invoke it, we usually seek a finer‑grained "unit".

We can understand code either from the outside via automated tests or from the inside, isolating it from the rest of the system.

Some people write a large "unit" of code and then use automated tests to verify its operation, but this approach is difficult, and larger units make test creation increasingly hard.

Therefore, the ease of writing test cases can serve as a probe for good design: if writing automated tests is painful, it indicates insufficient modularity and suggests making modules smaller.

If we treat testing merely as a tool, we can bypass debates about what constitutes a unit and its appropriate size; a unit can be a class, a function, or a cluster, but it should be small and isolated.

When your sense of a "unit" aligns with the simplest structure your technology provides, achieving modularity and encapsulation, that is ideal.

Easy unit tests target a specific type of interface, cover few cases, avoid extensive setup, and record a simple, understandable entity—a unit.

If it is hard to write tests for a code segment, it signals that the code could be more modular and that modules should be relatively small.

Ensuring tests are unique, understandable, and their behavior observable is often the first step toward deeper system comprehension.

Building on a solid understanding of how each part works allows you to reason about the whole system, and errors become signs of misunderstanding; good modularity improves overall system quality.

Teacher Qiao Liang is launching a video course "Continuous Deployment Training Camp (Python Edition)" at a limited‑time special price.

Is your software development efficiency high enough? Is the quality sufficient? How quickly can your team push production changes to users? Do you feel pressure over delivery quality, experience deployment failures, or even downtime? Continuous deployment can eliminate these pains, letting you focus on high‑value customer needs while reducing effort on delivery execution issues. This course combines theory and practice, teaching you to build‑test‑deploy pipelines, practice gradual feature releases, and handle database schema changes.

(Scan QR code to subscribe)