Skip to content

PATTERN Cited by 1 source

Destructive testing on ephemeral branch

Pattern

When database branching offers sub-second reset at zero storage cost, destructive testing becomes a daily development option rather than a quarterly operations exercise. The blast radius of any destructive action on a branch is zero — the parent and all other branches are unaffected. Reset means: delete the branch and create a fresh one off the same parent in ~1 second.

What fits inside a normal feature cycle

  • Migration failure at midpoint. Run the migration. Kill the process at 50% through the UPDATE. Verify rollback behaviour. Reset.
  • Partial backup-restore during failover. Simulate the partial state. Verify application behaviour. Reset.
  • DR runbook timing. Run the full disaster-recovery runbook. Measure actual time-to-recovery. Reset.
  • Edge-case data corruption. Seed ~1% corrupted values (missing digits, embedded spaces, trailing whitespace) into production-shaped data. Run the migration. Verify it handles the edge cases. Reset.

Cultural effect

When reset costs nothing, teams stop treating the test database as a precious resource. Tests can be aggressive. Cleanup is unnecessary because the next branch starts fresh. The approval-gate and ops-calendar overhead associated with destructive testing disappears.

Canonical example

Before opening her PR, Jen took the production-shaped data on her branch and deliberately corrupted around one percent of the inventory_code values to look like edge cases: missing digits, embedded spaces, trailing whitespace — the artifacts that historical data accumulates. She ran her migration. Two rows failed her substring math. She fixed the script and re-ran. The branch absorbed the destructive test. Production never saw it.

(Source: sources/2026-06-05-databricks-enabling-evolutionary-database-development-database-branchin)

Anti-patterns

  • Running destructive tests on shared environments. The blast radius is no longer zero; other developers' work is affected.
  • Skipping destructive tests because "the migration looks simple." The whole point of near-free branching is that validation cost is negligible — there's no reason not to test.
Last updated · 542 distilled / 1,571 read