5 Testing

Tests are the only safety net that allows a codebase to evolve. Without them, every refactor is a gamble. With them, you can reshape architecture with confidence. This chapter is in three parts. The first covers the fundamentals — the universal concepts that apply across all kinds of testing: keeping tests free of logic, understanding what coverage metrics actually measure, and using property-based testing to find the edge cases you didn't think to write. The second part zooms in on the most common kind of test in practice, the unit test: what makes one good, why they double as documentation, and the single most important rule for writing them — test behavior, not implementation. The chapter closes with Test-Driven Development, treated honestly as a useful tool for some people in some situations rather than as a quality gate or a moral position. Throughout, the goal is to move beyond writing tests to designing testable systems — maximizing confidence while minimizing the maintenance burden that bad tests inflict on a team.

5.1 Fundamentals

5.1.1 Avoiding Logic in Tests

5.1.2 Code Coverage

5.1.3 Line vs. Branch Coverage

5.2 Property-Based Testing

5.2.1 Traditional Tests

5.2.2 The Limitations of Traditional Tests

5.2.3 Exploring Property-Based Testing

5.2.4 Going Beyond

5.3 Unit Tests

5.3.1 Common Arguments Against Unit Tests

5.3.2 The code is too simple to need tests

5.3.3 I will add tests later

5.3.4 Testing is for testers

5.3.5 We will catch issues during integration tests

5.3.6 This code is just temporary, so it doesn’t need tests

5.3.7 I don’t have time to write unit tests

5.3.8 This code didn’t have unit tests, so why start now?

5.3.9 This project is just a PoC; it won’t go into production

5.3.10 It’s just a cleanup, no need to add tests

5.3.11 10 Unit Tests Properties

5.4 Unit Tests As Documentation

5.5 Test Behavior, Not Implementation