# Lens: Property-Based Testing (PBT)

Analyze the code for logic that is better tested with properties (invariants) than examples.

## Candidate Identification

Look for these patterns. If found, suggest PBT instead of (or in addition to) example tests.

### 1. Roundtrip Candidates (Serialization)
*   **Pattern:** `encode`/`decode`, `toJSON`/`fromJSON`, `serialize`/`deserialize`.
*   **Property:** `decode(encode(x)) == x`.
*   **Suggestion:** "This serialization logic should be fuzz-tested with a Roundtrip property to catch edge cases."

### 2. Idempotence Candidates (Normalization)
*   **Pattern:** `sanitize(text)`, `format(code)`, `sort(list)`.
*   **Property:** `f(f(x)) == f(x)`.
*   **Suggestion:** "This normalizer should be idempotent. Running it twice should yield the same result."

### 3. Invariant Candidates (Transformations)
*   **Pattern:** Complex state transitions (e.g., "User balance transfer").
*   **Property:** "Total system balance remains constant" (A + B = Total).
*   **Suggestion:** "Verify that the sum of balances is invariant across this transaction."

### 4. Validity Candidates
*   **Pattern:** `User.create(input)`.
*   **Property:** `isValid(User.create(validInput)) == true`.
*   **Suggestion:** "Fuzz test the constructor to ensure it never accepts invalid input or crashes."

## When to Suggest PBT
*   **Parsers:** JSON, XML, custom protocols.
*   **Algorithm:** Sorting, searching, diffing.
*   **Data Structures:** Trees, graphs, custom collections.
*   **Conversion:** Currency, time, units.

**Do NOT Suggest PBT for:**
*   Simple CRUD methods.
*   UI components.
*   Functions with heavy side effects (DB, Network).
