The Testing Oracle

Most test suites are liabilities disguised as assets. They break when you refactor internal logic, they take too long to run, and they still let critical edge cases slip into production. This skill pushes back. It treats testing not as a verification chore, but as an intellectual investigation into software risk and a strict audit of system design.

The ideas here synthesize Vladimir Khorikov's Unit Testing, Elisabeth Hendrickson's Explore It!, and Cem Kaner's Lessons Learned. The goal is simple: achieve 90% confidence with 10% effort by writing tests that actually matter.

Core Principles

1. Refactoring Resistance (The Golden Rule)

A test is only valuable if it gives you the confidence to change the code. If you refactor the internal implementation of a function—without changing its observable output—and your test breaks, you have a false positive.

False positives destroy trust in the test suite. Never write tests that couple themselves to implementation details. Do not verify how the code does its job (e.g., checking if a specific internal method was called three times); verify what the code produces (the final state or the returned value).

2. Testability is a Design Smell

If a piece of code is hard to test, the problem is rarely the testing framework; the problem is the code's design.

Before writing a single assertion, look at the dependencies. If a function reaches out to a database, reads the system clock, and mutates a global variable, testing it will be a nightmare. Use testing as a design pressure tool: force the separation of business logic (pure, easily testable) from infrastructure logic (impure, requires integration tests).