Introduction: Beyond "Example-Based" Testing

The Limits of "Standard" Unit Tests

Most developers learn to write unit tests using specific examples.

• Scenario: Testing a calculator addition function.
• Test: If I input 2 and 2, I expect 4.

This is called Example-Based Testing (EBT). It is excellent and necessary, but it has a fundamental flaw: it only tests the scenarios you can think of. Your test suite is bounded by your imagination — and your imagination is bounded by your assumptions.

What if someone inputs the maximum possible integer plus one? What if they input a Japanese character string instead of a number? What if they input negative zero? What if the list has exactly one item, or is empty? These are the unknown unknowns — the bugs that live in the gaps between the examples you wrote.

As systems grow complex, humans are systematically bad at predicting every possible edge case. We write tests that confirm our assumptions rather than challenge them.

A Map of What's Ahead

This lesson covers four techniques that go beyond standard unit testing, each designed to find bugs you didn't know existed:

1. Property-Based Testing (PBT): Instead of writing specific inputs, you define rules — invariants that must always hold — and a library generates thousands of random inputs to try and break those rules.
2. Fuzzing: A lower-level, more aggressive cousin of PBT that hurls raw, malformed data at program interfaces to find crashes and security vulnerabilities.
3. Mocks vs. Stubs: How to correctly fake external systems (like payment gateways or databases) to isolate the code you are actually testing, and how to avoid the trap of over-mocking.
4. Integration Testing with Docker: Spinning up real, throwaway databases and message queues so your tests run against actual infrastructure without the fragility of shared test environments.

These techniques are not replacements for each other. They form a layered strategy: unit tests with good mocks catch logic errors fast, PBT finds edge cases in algorithms, fuzzing finds security holes in parsers, and Docker-based integration tests catch the gaps between components.