Jump into concepts and practice - no test required
or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Recall & Review
beginner
What is a shared expensive resource in pytest?
A shared expensive resource is a setup or object that takes a lot of time or resources to create, so it is created once and reused across multiple tests to save time.
Click to reveal answer
beginner
How does pytest's @pytest.fixture(scope='session') help with shared expensive resources?
It creates the resource once per test session and shares it with all tests, avoiding repeated expensive setup.
Click to reveal answer
intermediate
Why should you avoid using scope='module' for very expensive resources in pytest?
Because if tests run in parallel or across multiple modules, the resource might be recreated multiple times, losing the benefit of sharing.
Click to reveal answer
intermediate
What is the purpose of the yield statement in a pytest fixture for shared resources?
It allows setup before yield and cleanup after, ensuring the expensive resource is properly released after all tests use it.
Click to reveal answer
advanced
How can you ensure thread safety when sharing an expensive resource in pytest?
By using locks or synchronization inside the fixture or resource to prevent conflicts when tests run in parallel.
Click to reveal answer
Which pytest fixture scope is best for sharing a resource across all tests in a session?
Aclass
Bsession
Cfunction
Dmodule
✗ Incorrect
The 'session' scope creates the fixture once per test session, ideal for expensive shared resources.
What does the yield keyword do in a pytest fixture?
AIt skips the fixture setup
BIt returns a value and ends the fixture immediately
CIt pauses the fixture to run tests, then resumes for cleanup
DIt marks the fixture as asynchronous
✗ Incorrect
Yield allows setup before tests run and cleanup after tests finish using the fixture.
Why is sharing expensive resources beneficial in testing?
AIt causes flaky tests
BIt makes tests run slower
CIt increases memory usage unnecessarily
DIt reduces test execution time by avoiding repeated setup
✗ Incorrect
Sharing expensive resources saves time by creating them once and reusing them.
If tests run in parallel, what must you consider when sharing resources?
AThread safety and synchronization
BIgnoring resource conflicts
CCreating a new resource for each test
DDisabling parallel execution
✗ Incorrect
Parallel tests need thread-safe shared resources to avoid conflicts.
Which fixture scope creates a new resource for every test function?
Afunction
Bsession
Cmodule
Dpackage
✗ Incorrect
The 'function' scope creates a fresh fixture for each test function.
Explain how to create and use a shared expensive resource in pytest using fixtures.
Think about how to write a fixture that runs once and cleans up after all tests.
You got /5 concepts.
Describe challenges and solutions when sharing expensive resources in parallel pytest runs.
Consider what happens if multiple tests access the same resource at the same time.
You got /5 concepts.
Practice
(1/5)
1. What is the main benefit of using a pytest fixture with a scope='module' when dealing with expensive resources?
easy
A. The fixture runs only once per test session, regardless of module.
B. The fixture setup runs once per module, reducing repeated expensive setup.
C. The fixture runs before every test function, ensuring fresh resources.
D. The fixture runs after each test to clean up resources immediately.
Solution
Step 1: Understand fixture scopes in pytest
Fixtures with scope='module' run once per module, not per test function.
Step 2: Relate scope to expensive resource usage
Running setup once per module saves time by avoiding repeated expensive setups for each test.
Final Answer:
The fixture setup runs once per module, reducing repeated expensive setup. -> Option B
Quick Check:
Module scope = setup once per module [OK]
Hint: Module scope runs setup once per module, saving time [OK]
Common Mistakes:
Confusing module scope with function scope
Thinking setup runs before every test
Assuming cleanup runs immediately after each test
2. Which of the following is the correct syntax to define a pytest fixture that sets up a database connection once per test session?
easy
A. @pytest.fixture(scope='session')\ndef db_conn():\n pass
B. @pytest.fixture(scope='class')\ndef db_conn():\n pass
C. @pytest.fixture(scope='module')\ndef db_conn():\n pass
D. @pytest.fixture(scope='function')\ndef db_conn():\n pass
Solution
Step 1: Identify scope for once per test session
The session scope runs the fixture setup once for the entire test session.
Step 2: Match syntax with correct scope
@pytest.fixture(scope='session')\ndef db_conn():\n pass uses @pytest.fixture(scope='session'), which is correct for this purpose.
Final Answer:
@pytest.fixture(scope='session')\ndef db_conn():\n pass -> Option A
Quick Check:
Session scope = setup once per session [OK]
Hint: Session scope means setup runs once per entire test run [OK]
Common Mistakes:
Using function scope for expensive shared resources
Confusing module and session scopes
Forgetting to specify scope in fixture decorator
3. Given the following pytest fixture and test code, what will be the output when running the tests?
@pytest.fixture(scope='module')
def resource():
print('Setup resource')
yield
print('Cleanup resource')
def test_one(resource):
print('Test one running')
def test_two(resource):
print('Test two running')
medium
A. Setup resource\nTest one running\nTest two running\nCleanup resource
B. Setup resource\nTest one running\nCleanup resource\nSetup resource\nTest two running\nCleanup resource
C. Test one running\nTest two running
D. Setup resource\nCleanup resource\nTest one running\nTest two running
Solution
Step 1: Understand module scope fixture behavior
With scope='module', setup runs once before any tests in the module, and cleanup runs after all tests finish.
Step 2: Trace the print statements during test execution
First, 'Setup resource' prints. Then 'Test one running' and 'Test two running' print during tests. Finally, 'Cleanup resource' prints after all tests.
Final Answer:
Setup resource\nTest one running\nTest two running\nCleanup resource -> Option A
Quick Check:
Module scope = setup once before all tests, cleanup after all [OK]
Hint: Module scope runs setup once before all tests, cleanup after all [OK]
Common Mistakes:
Expecting cleanup after each test
Thinking setup runs before each test
Ignoring yield behavior in fixture
4. Identify the error in this pytest fixture code that aims to share a resource across tests in a class:
A. The fixture should use scope='module' instead of 'class'.
B. The fixture function name does not match the test parameter name.
C. The fixture does not handle exceptions during resource setup.
D. The fixture is missing the @pytest.mark.usefixtures decorator.
Solution
Step 1: Review fixture resource setup and cleanup
The fixture opens a file and yields it, then closes it after tests.
Step 2: Check for error handling in setup
If opening the file fails, no exception handling is present, which can cause test failures or resource leaks.
Final Answer:
The fixture does not handle exceptions during resource setup. -> Option C
Quick Check:
Missing exception handling in fixture setup = problem [OK]
Hint: Always handle exceptions in fixture setup to avoid leaks [OK]
Common Mistakes:
Confusing fixture scope requirements
Thinking @pytest.mark.usefixtures is mandatory
Assuming fixture name mismatch causes error
5. You want to share a database connection across multiple test classes but ensure it resets after all tests finish. Which pytest fixture pattern correctly achieves this?
hard
A. @pytest.fixture(scope='function')\ndef db_conn():\n conn = connect_db()\n yield conn\n conn.reset()\n conn.close()
B. @pytest.fixture(scope='class')\ndef db_conn():\n conn = connect_db()\n yield conn\n conn.close()
C. @pytest.fixture(scope='module')\ndef db_conn():\n conn = connect_db()\n yield conn\n conn.reset()
D. @pytest.fixture(scope='session')\ndef db_conn():\n conn = connect_db()\n yield conn\n conn.reset()\n conn.close()
Solution
Step 1: Determine scope for sharing across multiple test classes
Sharing across classes requires at least session scope to cover all tests.
Step 2: Ensure resource resets after all tests finish
Using yield allows cleanup code after tests; calling conn.reset() before conn.close() resets the connection properly.