Bird
Raised Fist0
Testing Fundamentalstesting~15 mins

Database migration testing in Testing Fundamentals - Build an Automation Script

Choose your learning style10 modes available
Verify data integrity after database migration
Preconditions (3)
Step 1: Connect to the source database and export the test data from the 'users' table
Step 2: Run the migration script/tool to migrate data from source to target database
Step 3: Connect to the target database and query the 'users' table
Step 4: Compare the data in the source and target 'users' tables for all columns
Step 5: Verify that the number of records in both tables is the same
Step 6: Verify that no data is lost or altered during migration
✅ Expected Result: All records in the 'users' table are migrated correctly with identical data and record count in the target database
Automation Requirements - Python with pytest and psycopg2 for PostgreSQL
Assertions Needed:
Assert that record counts in source and target tables are equal
Assert that each record's data matches exactly between source and target
Best Practices:
Use database connection pooling or context managers to manage connections
Use parameterized queries to avoid SQL injection
Fetch data in a consistent order for comparison
Use clear and descriptive assertion messages
Handle exceptions and close connections properly
Automated Solution
Testing Fundamentals
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.

Common Mistakes - 4 Pitfalls
{'mistake': 'Not ordering the data before comparison', 'why_bad': 'Data fetched from databases can be in any order, causing false mismatches', 'correct_approach': "Always use ORDER BY clause on a unique column like 'id' to get consistent order"}
Not closing database connections
{'mistake': 'Comparing only record counts without data validation', 'why_bad': 'Record counts can match but data might be corrupted or incomplete', 'correct_approach': "Compare each record's data fields to ensure full integrity"}
Hardcoding credentials in test code
Bonus Challenge

Now add data-driven testing with 3 different tables: 'users', 'orders', and 'products' to verify migration for each

Show Hint

Practice

(1/5)
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
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard