Fundamentals 9 min read

Practical Guide to Unit Testing: Principles, Practices, and When to Apply Them

This article offers a practical, experience‑based overview of unit testing, explaining why it matters, what makes a good test, when to write or skip tests, who should write them, and how to structure them effectively for reliable software quality.

Continuous Delivery 2.0
Continuous Delivery 2.0
Continuous Delivery 2.0
Practical Guide to Unit Testing: Principles, Practices, and When to Apply Them

The author, who recently resumed work in engineering productivity, describes guiding product teams through the first stage of business requirement collaboration, emphasizing rapid problem discovery, quick solutions, and confidence building.

To further improve team quality, the author introduces a "quality built‑in" phase by moving toward flattened testing, referencing Chapter 10 of "Continuous Delivery 2.0" on automated test management.

Recognizing the difficulty of this step, the author highlights the need for a capable team lead (named @修罗王) with experience at a major tech company, and shares his compelling airplane‑and‑flight‑test metaphor for unit testing.

The author notes that, like continuous integration, testing practices only reveal their true value after sustained application and reflection.

He clarifies that the article will not delve into theoretical distinctions such as Utest vs. TDD, focusing instead on pragmatic engineering rules.

0 – Unit Testing and New Aircraft Quality

Unit testing is presented as the most effective way to ensure code produces the intended results, analogous to testing each aircraft component before assembly.

1 – What Makes a Good Unit Test

A good unit test must be correct, clear, complete, and robust; it should verify code correctness, aid understanding, achieve high coverage, and remain stable despite internal changes.

2 – What Should Unit Tests Verify?

Unit tests should focus on the "what" (behaviour) rather than the "how" (implementation), testing distinct input‑output behaviours independently.

3 – When to Write Unit Tests

The author prefers writing tests alongside implementation to validate design decisions early and improve efficiency.

4 – When Unit Tests May Be Skipped

Rare cases for skipping tests include extremely simple inline functions, legacy complex code without test expectations, low‑impact code, or situations where testing is impractically difficult.

5 – Who Should Write Unit Tests

Developers who write production code should also write the corresponding unit tests; dedicated test engineers should focus on frameworks, automation, and infrastructure.

6 – How to Write Unit Tests

A classic three‑step structure—Arrange, Act, Assert—is recommended, with clear separation of preparation, invocation, and verification.

7 – Additional Tips for Writing Unit Tests

Key advice includes giving tests meaningful names, avoiding complex logic within tests, ensuring tests are comprehensive yet non‑redundant, testing only public interfaces, and keeping the test environment as close as possible to production.

software engineeringsoftware qualityunit testingtest-driven developmentcode robustness
Continuous Delivery 2.0
Written by

Continuous Delivery 2.0

Tech and case studies on organizational management, team management, and engineering efficiency

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.