Database migration testing in Testing Fundamentals - Framework Patterns

Framework Mode - Database migration testing

Folder Structure for Database Migration Testing Framework

database-migration-testing/
├── migrations/               # Migration scripts (SQL or migration tool files)
│   ├── V1__initial_schema.sql
│   ├── V2__add_new_table.sql
│   └── ...
├── tests/                    # Automated tests for migration verification
│   ├── test_data_integrity.py
│   ├── test_schema_changes.py
│   └── test_performance.py
├── utils/                    # Helper scripts and utilities
│   ├── db_connection.py
│   ├── data_generator.py
│   └── migration_runner.py
├── config/                   # Configuration files for environments
│   ├── dev_config.yaml
│   ├── staging_config.yaml
│   └── prod_config.yaml
├── reports/                  # Test execution reports
│   └── migration_test_report.html
├── conftest.py               # Pytest fixtures for DB setup/teardown
└── README.md                 # Documentation

Test Framework Layers for Database Migration Testing

• Migration Scripts Layer: Contains all database migration files that change schema or data.
• Test Layer: Automated tests that verify schema correctness, data integrity, and performance after migration.
• Utility Layer: Helper modules for database connections, running migrations, and generating test data.
• Configuration Layer: Environment-specific settings like database URLs, credentials, and migration tool options.
• Reporting Layer: Generates readable test reports showing pass/fail status and details.

Configuration Patterns

• Use separate config files (YAML/JSON) for each environment (dev, staging, prod) to store DB connection info and migration settings.
• Load config dynamically in tests and utilities to connect to the correct database.
• Secure sensitive data like passwords using environment variables or secret managers, not hardcoded.
• Parameterize migration runner to accept target version and environment for flexible testing.

Test Reporting and CI/CD Integration

• Use test frameworks (e.g., Pytest) with plugins to generate HTML or XML reports summarizing migration test results.
• Integrate migration tests into CI/CD pipelines to run automatically on migration script changes.
• Fail the pipeline if any migration test fails to prevent faulty migrations from deploying.
• Store reports as artifacts in CI/CD for audit and troubleshooting.

Best Practices for Database Migration Testing Framework

1. Test Early and Often: Run migration tests on every migration script before production deployment.
2. Isolate Test Environments: Use separate test databases to avoid affecting real data.
3. Automate Rollbacks: Include tests that verify rollback scripts or migration reversions work correctly.
4. Validate Both Schema and Data: Check that schema changes apply correctly and existing data remains consistent.
5. Use Idempotent Migrations: Ensure migrations can run multiple times safely to avoid errors.

Self-Check Question

Where in this folder structure would you add a new automated test that verifies data consistency after migration?

Key Result

Organize migration scripts, tests, utilities, and configs clearly to automate and verify database schema and data changes safely.

Practice

1. What is the main goal of database migration testing?

easy

A. To redesign the database schema

B. To check the speed of the new database server

C. To verify that data is correctly and completely moved from the old database to the new one

D. To backup the database before migration

Solution

1. Step 1: Understand the purpose of migration testing

   Migration testing focuses on ensuring data integrity and completeness after moving data.

2. Step 2: Identify the main goal

   The main goal is to verify data correctness and completeness in the new database.

3. Final Answer:

   To verify that data is correctly and completely moved from the old database to the new one -> Option C

4. Quick Check:

   Migration testing = Data correctness and completeness [OK]

Hint: Focus on data correctness and completeness in migration [OK]

Common Mistakes:

• Confusing migration testing with performance testing
• Thinking migration testing is about database design
• Assuming backup is the main goal

2. Which of the following is the correct SQL query to count rows in a table named users for migration testing?

easy

A. SELECT COUNT(*) FROM users;

B. SELECT COUNT FROM users;

C. COUNT FROM users;

D. SELECT * FROM users COUNT;

Solution

1. Step 1: Recall correct SQL syntax for counting rows

   The correct syntax uses SELECT COUNT(*) FROM table_name;

2. Step 2: Match options with correct syntax

   SELECT COUNT(*) FROM users; matches the correct syntax exactly.

3. Final Answer:

   SELECT COUNT(*) FROM users; -> Option A

4. Quick Check:

   Count rows = SELECT COUNT(*) FROM table [OK]

Hint: Use SELECT COUNT(*) FROM table_name; for row counts [OK]

Common Mistakes:

• Using COUNT without SELECT
• Placing COUNT after * incorrectly
• Omitting parentheses in COUNT

3. Given the following data in the old database table products:

id | name    | price
1  | Pen     | 1.20
2  | Notebook| 2.50
3  | Eraser  | 0.80

After migration, the products table in the new database has:

id | name    | price
1  | Pen     | 1.20
2  | Notebook| 2.50

What is the best conclusion?

medium

A. Migration is successful; all data is present

B. Migration failed; table structure is incorrect

C. Migration partially succeeded; price values changed

D. Migration failed; some data is missing

Solution

1. Step 1: Compare row counts and data between old and new tables

   The old table has 3 rows; the new table has only 2 rows.

2. Step 2: Identify missing data

   The row with id 3 (Eraser) is missing in the new table, indicating incomplete migration.

3. Final Answer:

   Migration failed; some data is missing -> Option D

4. Quick Check:

   Missing rows = Migration failure [OK]

Hint: Check row counts and sample data for missing records [OK]

Common Mistakes:

• Ignoring missing rows
• Assuming price changes mean failure
• Confusing structure issues with data issues

4. You wrote a script to compare row counts between old and new databases but it always shows zero for the new database. What is the most likely error?

medium

A. The script is connecting to the wrong new database instance

B. The old database is empty

C. The SQL query syntax is incorrect for the old database

D. The script is not counting rows in the old database

Solution

1. Step 1: Analyze why new database row count is always zero

   If the new database count is always zero, the script might be querying the wrong database or empty table.

2. Step 2: Identify the most common cause

   Connecting to the wrong new database instance is a frequent mistake causing zero counts.

3. Final Answer:

   The script is connecting to the wrong new database instance -> Option A

4. Quick Check:

   Zero count new DB = Wrong connection [OK]

Hint: Verify database connection details carefully [OK]

Common Mistakes:

• Assuming old database is empty without checking
• Blaming SQL syntax for new DB count
• Ignoring connection strings

5. During migration testing, you notice that some records with NULL values in the old database are missing in the new database after migration. What is the best approach to handle this?

hard

A. Ignore NULL records as they are not important

B. Modify the migration script to correctly handle NULL values and rerun migration tests

C. Delete NULL records from the old database before migration

D. Change NULL values to empty strings in the new database manually

Solution

1. Step 1: Identify the issue with NULL values in migration

   Missing records with NULL values indicate the migration script does not handle NULLs properly.

2. Step 2: Choose the best corrective action

   Modifying the migration script to handle NULLs ensures data completeness and correctness.

3. Final Answer:

   Modify the migration script to correctly handle NULL values and rerun migration tests -> Option B

4. Quick Check:

   Handle NULLs in script = Complete migration [OK]

Hint: Always handle NULLs explicitly in migration scripts [OK]

Common Mistakes:

• Ignoring NULL records thinking they are unimportant
• Manually changing data after migration
• Deleting data from source database