Database migration testing in Testing Fundamentals - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to check if the new database schema has the expected table.

Testing Fundamentals

assert '[1]' in new_db.get_tables()

Drag options to blanks, or click blank then click option'

Aconnect

Busers

Cmigrate

Drollback

Attempts:

3 left

💡 Hint

Common Mistakes

Using method names instead of table names.

Forgetting to put the table name as a string.

The assertion checks if the 'users' table exists in the new database schema after migration.

2fill in blank

medium

Complete the code to verify the row count matches before and after migration.

Testing Fundamentals

assert old_db.count_rows('orders') [1] new_db.count_rows('orders')

Drag options to blanks, or click blank then click option'

A!=

B<

C>

D==

Attempts:

3 left

💡 Hint

Common Mistakes

Using inequality operators which would fail the test.

Confusing greater than or less than operators.

The row count should be equal before and after migration to ensure data integrity.

3fill in blank

hard

Fix the error in the assertion that checks if a column exists in the migrated table.

Testing Fundamentals

assert '[1]' in new_db.get_columns('customers')

Drag options to blanks, or click blank then click option'

Acustomers

Bget_columns

Ccustomer_id

Dassert

Attempts:

3 left

💡 Hint

Common Mistakes

Using method names or table names instead of column names.

Using keywords like 'assert' in place of column names.

The assertion verifies that the 'customer_id' column exists in the 'customers' table after migration.

4fill in blank

hard

Fill both blanks to create a dictionary comprehension that maps table names to their row counts after migration.

Testing Fundamentals

row_counts = {table: new_db.[1](table) for table in new_db.[2]()}

Drag options to blanks, or click blank then click option'

Acount_rows

Bget_tables

Ctables

Dfetch_rows

Attempts:

3 left

💡 Hint

Common Mistakes

Using incorrect method names that do not exist.

Using variable names instead of method calls.

The comprehension uses count_rows to get row counts for each table returned by get_tables.

5fill in blank

hard

Fill all three blanks to filter migrated tables with more than 1000 rows and create a summary dictionary.

Testing Fundamentals

summary = {tbl: new_db.[1](tbl) for tbl in new_db.[2]() if new_db.[3](tbl) > 1000}

Drag options to blanks, or click blank then click option'

Acount_rows

Bget_tables

Dfetch_data

Attempts:

3 left

💡 Hint

Common Mistakes

Using different methods for counting rows in blanks 1 and 3.

Using a method that does not return tables for blank 2.

The code counts rows for each table from get_tables() and filters those with more than 1000 rows.

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