Sample questions
Sd Test Framework DesignDifficulty 1
In the simplest sense, what is a test framework responsible for that a plain scripting language on its own is not?
- aWriting the production code that the tests will exercise
- bDiscovering test cases, running them in a consistent way, and reporting pass/fail results✓
- cDeploying the application to a production server after tests pass, including provisioning new servers and rotating deployment credentials
- dReplacing the need for developers to write any assertions at all
Explanation:A test framework's core job is discovery (finding test functions/classes), execution (running them consistently with setup/teardown), and reporting (collecting and presenting pass/fail results) — that is (b). Frameworks do not write production code (a), do not handle deployment (c), and still require developers to write assertions themselves (d).
Sd Test Framework DesignDifficulty 1
What is the primary purpose of an assertion library within a test framework?
- aTo compare an actual value against an expected value and raise a clear failure when they do not match✓
- bTo automatically retry a test until it passes
- cTo generate random test data for every test run
- dTo manage database connections used by integration tests, including opening connection pools and rotating credentials between test runs
Explanation:An assertion library's job is to compare actual vs. expected values and, on mismatch, raise a failure with a clear message describing what went wrong — that is (a). Retrying tests (b), generating random data (c), and managing DB connections (d) are unrelated concerns handled by other parts of a test stack.
Sd Test Framework DesignDifficulty 2
In pytest, a function decorated with @pytest.fixture named db_connection is requested by a test simply by adding db_connection as a parameter name to the test function. What mechanism makes this work?
- apytest scans the test file's imports and matches them alphabetically to fixture names
- bThe test must call
db_connection() manually inside its body for the fixture to run - cpytest inspects the test function's parameter names and injects the matching fixture's return/yield value✓
- dFixtures are only available if explicitly listed in a
conftest.py __all__ variable
Explanation:pytest's fixture system works by dependency injection based on parameter names: it inspects a test function's signature, finds parameters that match registered fixture names, and injects each fixture's return (or yielded) value automatically — that is (c). There is no import-based matching (a), no manual call is required since pytest calls the fixture (b), and fixtures do not require an __all__ listing in conftest.py (d).
Sd Test Framework DesignDifficulty 2
A team writes their own assertion helper assertEqual(actual, expected) that just does if actual != expected: raise AssertionError() with no message. Why is this a poor design for an assertion library?
- aBecause
!= cannot compare two integers in any programming language, since comparison operators are only defined for strings and floating-point values - bBecause raising
AssertionError is not supported by any test runner - cBecause it silently passes when the values are actually different
- dBecause a failure gives no information about what the actual and expected values were, making debugging harder✓
Explanation:A core value of a good assertion library is a diagnostic failure message that shows the actual and expected values so a developer can debug without adding print statements — an empty AssertionError() loses that information entirely, which is (d). Integer comparison with != works fine (a), AssertionError is the standard exception most runners recognize (b), and the check correctly fails on a real mismatch (c).
Sd Test Framework DesignDifficulty 2
In JUnit 5, what is the role of an Extension (e.g. a class implementing BeforeEachCallback)?
- aIt plugs custom behavior into the test lifecycle, such as running code before each test method, without modifying the test class itself✓
- bIt replaces the need to write
@Test annotations on any test method, because extensions automatically discover and register every method in a class as a runnable test case - cIt is only used to change the console color of test output
- dIt compiles the test classes into bytecode before execution
Explanation:JUnit 5's extension model lets you plug reusable behavior into the test lifecycle (before/after each test, before/after all, parameter resolution, etc.) by implementing extension interfaces, without touching the test class body itself — that is (a). Extensions do not remove the need for @Test (b), are not limited to console coloring (c), and play no role in bytecode compilation (d).
Sd Test Framework DesignDifficulty 1
What does a test runner's "discovery" phase typically do?
- aIt measures how long the previous test run took to execute, and automatically adjusts the timeout for the next run based on that historical duration
- bIt fixes bugs found by failing tests automatically
- cIt scans the codebase to find files, classes, or functions that match the framework's test-naming convention✓
- dIt uploads test results to a cloud dashboard
Explanation:Discovery is the phase where a runner walks the codebase looking for items matching its naming convention (e.g. files starting with test_, functions prefixed test, classes annotated @Test) so it knows what to execute — that is (c). Timing (a), auto-fixing bugs (b), and uploading to a dashboard (d) are separate, optional concerns outside discovery.