Testing the Contract: Keeping Unit Tests Honest

Moshe Zadka

Unit tests are supposed to increase developer productivity, yet they often break when you refactor working code. The problem is that many tests enforce implementation details rather than the actual contract your code commits to.

In this talk, we'll explore what it means to test contracts instead of implementations. The "unit" in unit testing should be the publicly-observable behavior at your code's boundaries. We'll examine practical techniques for identifying the right testing boundaries and writing precise assertions using tools like PyHamcrest.

The payoff: tests that survive refactoring, faster development cycles, and a test suite that documents your system's actual behavior. Your tests should break when contracts are violated, not when you improve your code.

About Moshe Zadka

Moshe has been a DevOps/SRE since before those terms existed, caring deeply about software reliability, build reproducibility, and other such things. They have worked in companies as small as three people and as big as tens of thousands—usually someplace around where software meets system administration.