Engineering & performance / DIJION
Protect data during updates: mobile database migration tests
A migration test plan distinguishing fresh installs from upgrades, with checks for schemas, data meaning and skipped versions.
A new release can work on a fresh install while failing to open an existing user’s data. Adding a column or changing a field’s meaning requires more than creating the new table. In an illustrative notes app, inspect older untitled records and related objects. An upgrade test needs to start from a representative older state.
List the supported upgrade paths
People may skip intermediate releases. Identify supported paths from older versions to the new one instead of testing only the latest adjacent upgrade. Keep representative data alongside schema fixtures. Fixtures need not copy personal records; synthetic records can represent relevant edge cases without carrying real users’ information into development.
Separate valid structure from preserved meaning
Scroll the table horizontally to see all columns.
| Check | Example condition | Acceptance evidence |
|---|---|---|
| Structure | New required field | Valid schema |
| Meaning | Older empty title | Defined transformation |
| Relationship | Note and attachment | Preserved association |
Tools validate the schema; check the data separately
Android Room documentation notes that MigrationTestHelper verifies schema changes while correct data migration needs additional checks. The distinction is useful beyond that library: a table may open while a record points to the wrong account or a date has changed meaning. Launching without a crash is not sufficient evidence of a successful upgrade.
Plan recovery from interrupted migration
Define behavior after termination, low storage or malformed data. Verify the transaction guarantees of the chosen database rather than assuming every storage mechanism rolls back identically. Deleting local data and recreating storage can destroy user work. Any such behavior needs an explicit scope and a genuine recovery path.
Finish the upgrade with a product task
- Create a supported old schema with representative records.
- Upgrade directly and compare relationships and values.
- Include empty fields, long text and interruption scenarios.
- Edit a migrated record and reopen it to verify persistence.
The handoff defines supported paths and preserved data invariants. Release acceptance includes the continued correctness of existing user work, not just the appearance of the new version.