A leaky abstraction is a simplified model or interface that can't fully hide the complexity beneath it, so details from underneath show through in ways users of the abstraction have to deal with.
Why it matters: Every model is a simplification, so every model leaks somewhere. For testers, it's a reminder not to trust a risk model, diagram, framework or API too far, and to look for where its gaps might cause problems.
In practice: Testers ask where an abstraction might break down, such as under load, with unusual data or when something underneath changes. They test at the boundaries where hidden details are most likely to show through.
Examples:
- A database library that hides SQL until a slow query forces developers to understand it.
- A risk model that treats all users as the same until one group behaves very differently.
Common pitfalls:
- Spending effort perfecting an abstraction that will always leak somewhere.
- Testing only through the abstraction, and missing problems in what it hides.
Who coined the term leaky abstraction? The phrase was popularised by software writer Joel Spolsky, who described a law of leaky abstractions: all non-trivial abstractions, to some degree, are leaky.
