Characterization Tests

These tests don't check what the code should do. They record what it does do, today, so you can change it with a safety net. If the current behavior is a bug, the test still asserts the bug, with a comment. Fixing it is a separate, deliberate change.

Step 1: Draw the boundary

Pick the highest seam that covers the code you're about to change and that you can call from a test:

• An API endpoint (best: covers serializer, view, permissions, queryset)
• A service function or model method
• A Celery task body (call the function directly, not .delay)
• A management command (call_command)

Write down the inputs that matter: user roles, object states, flags/settings, dates. Read the code for branches (if, try, early returns) and list one case per branch. That's your case list. Show it to the dev before writing tests.

Step 2: Capture the current behavior

For each case: set up the state (factories / fixtures in the project's style), call the seam, and assert on everything observable: