Database migration testing in Testing Fundamentals - Build an Automation Script
import psycopg2 import pytest SOURCE_DB_CONFIG = { 'host': 'source-db-host', 'database': 'source_db', 'user': 'source_user', 'password': 'source_pass' } TARGET_DB_CONFIG = { 'host': 'target-db-host', 'database': 'target_db', 'user': 'target_user', 'password': 'target_pass' } def get_users_data(db_config): with psycopg2.connect(**db_config) as conn: with conn.cursor() as cur: cur.execute('SELECT id, username, email, created_at FROM users ORDER BY id') return cur.fetchall() @pytest.fixture(scope='module') def source_users(): return get_users_data(SOURCE_DB_CONFIG) @pytest.fixture(scope='module') def target_users(): return get_users_data(TARGET_DB_CONFIG) def test_user_data_migration(source_users, target_users): assert len(source_users) == len(target_users), f"Record count mismatch: source={len(source_users)}, target={len(target_users)}" for i, (src_row, tgt_row) in enumerate(zip(source_users, target_users), start=1): assert src_row == tgt_row, f"Data mismatch at record {i}: source={src_row}, target={tgt_row}"
This test script connects to both source and target PostgreSQL databases using psycopg2. It fetches all records from the users table ordered by id to ensure consistent comparison.
Fixtures source_users and target_users provide the data sets for the test function test_user_data_migration.
The test first asserts that the number of records is the same in both databases. Then it compares each record one by one to ensure data integrity.
Using context managers ensures connections and cursors are properly closed. Assertions include clear messages to help identify issues.
Now add data-driven testing with 3 different tables: 'users', 'orders', and 'products' to verify migration for each
Practice
database migration testing?Solution
Step 1: Understand the purpose of migration testing
Migration testing focuses on ensuring data integrity and completeness after moving data.Step 2: Identify the main goal
The main goal is to verify data correctness and completeness in the new database.Final Answer:
To verify that data is correctly and completely moved from the old database to the new one -> Option CQuick Check:
Migration testing = Data correctness and completeness [OK]
- Confusing migration testing with performance testing
- Thinking migration testing is about database design
- Assuming backup is the main goal
users for migration testing?Solution
Step 1: Recall correct SQL syntax for counting rows
The correct syntax uses SELECT COUNT(*) FROM table_name;Step 2: Match options with correct syntax
SELECT COUNT(*) FROM users; matches the correct syntax exactly.Final Answer:
SELECT COUNT(*) FROM users; -> Option AQuick Check:
Count rows = SELECT COUNT(*) FROM table [OK]
- Using COUNT without SELECT
- Placing COUNT after * incorrectly
- Omitting parentheses in COUNT
products:
id | name | price 1 | Pen | 1.20 2 | Notebook| 2.50 3 | Eraser | 0.80After migration, the
products table in the new database has:
id | name | price 1 | Pen | 1.20 2 | Notebook| 2.50What is the best conclusion?
Solution
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.Step 2: Identify missing data
The row with id 3 (Eraser) is missing in the new table, indicating incomplete migration.Final Answer:
Migration failed; some data is missing -> Option DQuick Check:
Missing rows = Migration failure [OK]
- Ignoring missing rows
- Assuming price changes mean failure
- Confusing structure issues with data issues
Solution
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.Step 2: Identify the most common cause
Connecting to the wrong new database instance is a frequent mistake causing zero counts.Final Answer:
The script is connecting to the wrong new database instance -> Option AQuick Check:
Zero count new DB = Wrong connection [OK]
- Assuming old database is empty without checking
- Blaming SQL syntax for new DB count
- Ignoring connection strings
Solution
Step 1: Identify the issue with NULL values in migration
Missing records with NULL values indicate the migration script does not handle NULLs properly.Step 2: Choose the best corrective action
Modifying the migration script to handle NULLs ensures data completeness and correctness.Final Answer:
Modify the migration script to correctly handle NULL values and rerun migration tests -> Option BQuick Check:
Handle NULLs in script = Complete migration [OK]
- Ignoring NULL records thinking they are unimportant
- Manually changing data after migration
- Deleting data from source database
Ready to prove it?
Pass the test and this pattern moves unknown
