Database migrations are the highest-risk operations in software development. A bad migration can lose data, corrupt records, or bring down the entire application. And they're notoriously hard to test.
AI coding tools make migration risk worse. They generate schema changes that look correct but miss subtle issues: columns dropped that other queries depend on, data types changed that break existing records, indexes removed that queries rely on for performance.
The Fortune story about an AI agent destroying an entire database illustrates the extreme case. But less dramatic migration bugs happen daily: a column type change that silently truncates data, a NOT NULL constraint added to a column with existing NULL values, a foreign key dropped that breaks a join used by the reporting dashboard.
What to Test in Database Migrations
Before migration: Backup verification. Rollback plan tested. Migration script reviewed for destructive operations.
During migration: Data integrity checks. Row counts match. Data types preserved. No silent truncation.
After migration: Application functions correctly with the new schema. All queries execute. Performance hasn't degraded. No orphaned references.
TestSprite tests the "after migration" layer comprehensively. After a migration deploys to your preview environment, the full test suite runs and verifies that every application flow still works correctly. If the migration broke a query, changed a data shape the frontend depends on, or introduced a performance regression, the tests catch it.
Database migrations are too important to test manually and too risky to skip testing entirely.