Testing with database in Flask - Cheat Sheet & Quick Revision

Recall & Review

beginner

Why do we use a separate test database when testing a Flask app?

We use a separate test database to keep test data isolated from real data. This prevents tests from changing or deleting important information and allows tests to run safely and repeatedly.

intermediate

What is the purpose of the Flask `app.app_context()` during database testing?

The `app.app_context()` provides the application context needed to access Flask's current app and database. It ensures database operations work correctly during tests outside normal request handling.

intermediate

How does using `setUp` and `tearDown` methods help in database testing?

The `setUp` method prepares a fresh test database before each test, and `tearDown` cleans up after the test. This keeps tests independent and avoids leftover data affecting other tests.

beginner

What is a common way to reset the database state between tests in Flask?

A common way is to drop all tables and recreate them before each test. This ensures each test starts with a clean database.

beginner

Why might you use an in-memory SQLite database for testing in Flask?

An in-memory SQLite database is fast and temporary. It exists only during the test run, so tests run quickly and leave no files behind.

What does the Flask `app.app_context()` provide during database tests?

A Access to the current Flask app and its resources

B A new database connection

C Automatic test data generation

D User authentication

The app context allows tests to access the Flask app and database correctly outside normal requests.

Why should tests use a separate test database?

A To share data between users

B To avoid changing real data during tests

C To speed up the app in production

D To enable user login

Using a separate test database keeps test data isolated and safe from affecting real data.

Which method is commonly used to prepare the database before each test?

A init

B tearDown

C setUp

D run

The setUp method sets up a fresh database state before each test.

What is a benefit of using an in-memory SQLite database for tests?

A It is fast and temporary

B It stores data permanently

C It requires no setup

D It supports multiple users

In-memory SQLite databases are fast and disappear after tests finish.

What does the `tearDown` method do in database testing?

A Runs the test suite

B Creates test data

C Starts the Flask app

D Cleans up the database after each test

tearDown cleans the database to keep tests independent.

Explain how to set up and clean a test database in Flask tests.

Think about preparing and resetting the database for each test.

Why is isolation important in database testing and how do Flask tests achieve it?

Consider how tests stay independent and safe.

Practice

1. What is the main purpose of using a test database in Flask testing?

easy

A. To store user sessions permanently

B. To isolate tests so they don't affect the real data

C. To speed up the app in production

D. To replace the main database in deployment

Solution

1. Step 1: Understand test database role

   A test database is used to keep test data separate from real data to avoid unwanted changes.

2. Step 2: Identify isolation benefit

   This isolation ensures tests do not affect the real app data or state.

3. Final Answer:

   To isolate tests so they don't affect the real data -> Option B

4. Quick Check:

   Test database isolates data = C [OK]

Hint: Test DB keeps test data separate from real data [OK]

Common Mistakes:

• Thinking test DB speeds up production
• Confusing test DB with session storage
• Assuming test DB replaces main DB in deployment

2. Which Flask testing method is used to prepare the test database before each test runs?

easy

A. tearDown

B. initTest

C. setUp

D. runTest

Solution

1. Step 1: Recall Flask test lifecycle methods

   In Flask testing, setUp runs before each test to prepare the environment.

2. Step 2: Match method to database preparation

   Preparing the test database (like creating tables) happens in setUp.

3. Final Answer:

   setUp -> Option C

4. Quick Check:

   Prepare DB before test = setUp [OK]

Hint: Use setUp to prepare before each test [OK]

Common Mistakes:

• Confusing tearDown with setup
• Using runTest which is not for setup
• Assuming initTest is a Flask method

3. Given this test code snippet, what will print(len(users)) output?

def test_user_creation(self):
    user = User(name='Anna')
    db.session.add(user)
    db.session.commit()
    users = User.query.all()
    print(len(users))

medium

A. 1

B. 0

C. Error: session not initialized

D. Multiple users depending on previous tests

Solution

1. Step 1: Analyze user addition and commit

   The code adds one user and commits to the test database.

2. Step 2: Query all users after commit

   Querying all users returns a list with the one added user.

3. Final Answer:

   1 -> Option A

4. Quick Check:

   One user added and committed = 1 [OK]

Hint: Commit before query to see added users [OK]

Common Mistakes:

• Forgetting to commit before query
• Assuming previous tests add users
• Thinking session is not initialized

4. What is wrong with this test code snippet?

def tearDown(self):
    db.session.remove()
    db.drop_all()

medium

A. Missing call to create_all() in tearDown

B. tearDown should not remove session

C. drop_all() should be in setUp, not tearDown

D. No call to rollback() before drop_all()

Solution

1. Step 1: Understand tearDown purpose

   tearDown cleans up after tests by removing session and dropping tables.

2. Step 2: Identify missing rollback before drop_all()

   Without rollback, pending changes may not be discarded, potentially causing errors or inconsistent state.

3. Final Answer:

   No call to rollback() before drop_all() -> Option D

4. Quick Check:

   Rollback before drop_all to discard changes [OK]

Hint: Always rollback before dropping tables in tearDown [OK]

Common Mistakes:

• Thinking create_all belongs in tearDown
• Believing session removal is wrong in tearDown
• Ignoring rollback before drop_all

5. You want to test a Flask app that uses a database. Which sequence correctly sets up and cleans the test database for each test?

hard

A. Call db.create_all() in setUp, run test, then db.drop_all() in tearDown

B. Call db.drop_all() in setUp, run test, then db.create_all() in tearDown

C. Call db.session.commit() in setUp, then db.session.remove() in tearDown

D. Call db.create_all() and db.drop_all() both in setUp

Solution

1. Step 1: Understand test setup and cleanup

   Creating tables before each test ensures a fresh database state.

2. Step 2: Understand test teardown

   Dropping tables after each test cleans up to avoid data carryover.

3. Step 3: Match correct sequence

   Calling create_all() in setUp and drop_all() in tearDown is the correct pattern.

4. Final Answer:

   Call db.create_all() in setUp, run test, then db.drop_all() in tearDown -> Option A

5. Quick Check:

   Create tables before, drop after test = A [OK]

Hint: Create tables before test, drop after test [OK]

Common Mistakes:

• Dropping tables before test instead of after
• Calling create_all and drop_all both in setUp
• Confusing commit with setup/teardown