tests-adversarial

Adversarial Testing — Think Like the Attacker

Every line of code makes assumptions. Your job is to find them and violate them — systematically, not randomly. The goal is distrust, not coverage. A passing test suite proves nothing if it only tests the happy path.

The Adversarial Mindset

1. Every input is a lie. Callers will send garbage, nulls, negative numbers, empty strings, and types that satisfy the compiler but violate intent.
2. Implicit contracts are targets. If the code assumes ordering, uniqueness, non-emptiness, or positive values without enforcing it — that is your entry point.
3. The system is your adversary. Files disappear, connections drop, clocks jump, memory runs out, permissions change between check and use.
4. Passing tests prove nothing. They prove the happy path works. Adversarial tests prove the sad paths do not silently corrupt.

Assumption Hunting (Core Technique)

For every function or module under test, ask these six questions:

1. What does it assume about inputs? Violate each assumption: wrong type coercion, boundary values, null/nil/None, empty collections, maximum-size payloads.
2. What does it assume about ordering? Reorder arguments, reverse sequences, interleave concurrent calls, call methods out of lifecycle order.
3. What does it assume about timing? Delay responses past timeouts, deliver results before the consumer is ready, inject clock skew, expire tokens mid-operation.
4. What does it assume about state? Start from half-initialized state, corrupt shared state mid-operation, test post-error recovery state, double-close resources.
5. What does it assume about resources? Exhaust file descriptors, fill disk, revoke permissions, return allocation failures, saturate connection pools.
6. What does it assume will NOT happen? Make it happen. Concurrent modification during iteration, recursive re-entry, self-referential data, stack overflow via deep nesting.

Attack Vectors (Thinking Prompts)