Testing quiz — 75 questions with answers and explanations

Answer: B

Scope. A unit test checks one isolated unit of logic and runs very fast. An integration test checks multiple parts wired together (service + real DB, API + handler); it is slower but catches errors where the parts connect.

Answer: C

Write a regression test that reproduces the bug. Order matters: write the test before fixing and confirm it's red — if it's green from the start, you haven't reproduced the bug correctly, and the fix may be in the wrong place.

Answer: B

One behavior per test (a few asserts describing that behavior are fine). When the test goes red, the test name should tell you immediately what's wrong without opening the code — that's the most practical criterion.

Answer: C

Usually the mock is hiding the broken part: the test mocks the API-calling or DB layer, so the bug lives in the very part that's mocked. The test is green because it only checks that the mock behaves as you declared.

Answer: A

Use userEvent (await user.type(...), await user.click(...)). It fires the full real event sequence — focus, keydown, input, change — so it catches bugs fireEvent misses, e.g. validation on blur.

Answer: A

Check the error log first, then run that exact test on your branch and on the base branch. Red on both means it's a pre-existing issue; red only on your branch means your change is the cause, even if it looks unrelated.

Answer: D

A stub supplies canned data so the code can continue. A mock additionally records calls and lets you assert *how it was called* (how many times, with which arguments). Stubs check results; mocks check interactions.

Answer: D

It may not be checking what you think. Common causes: the assertion sits in a callback that never runs, a missing await so the test ends before the assertion, or a trivially true condition.

Answer: B

Three quick things: the relevant tests for the files you changed, type checking (tsc --noEmit), and the linter. They catch most problems in a few dozen seconds, instead of waiting minutes for CI and pushing another tiny fix commit.

Answer: D

It makes tests immediately readable: the first part sets up data and conditions, the middle calls exactly one action under test, and the last asserts the result. Tests that drift from this structure — for example, multiple calls interleaved with assertions — are usually a sign they are checking too many things.

Answer: D

The name should state the condition and expected behavior, reading like a sentence: "returns an error when the amount is negative". When a test goes red in a CI report, the name is the only thing the reader sees first — if it doesn't describe the problem, they have to open the code to understand.

Answer: B

A good fit when the same logic needs checking against many input sets — validation, calculation, conversion. Each row in the table is a separately named case, so adding a boundary case costs one line and the failure still points to exactly which row is wrong.

Answer: C

A fake is a simplified implementation that actually runs — for example an in-memory data store. A mock exists to assert on calls: how many times it was called, with which arguments. A fake checks results, a mock checks interactions.

Answer: B

Many fast tests at the low level (unit), fewer in the middle (integration), and fewest at the end-to-end level. The reason is cost: end-to-end tests run slowly, tend to be flaky, and when they go red you have to dig to find which part broke.

Answer: B

Check only a few core flows: open the homepage, log in, perform one main action. The goal is to detect within one or two minutes that the just-deployed build is severely broken, so you can roll back before many users encounter it.

Answer: A

Compared to a specific expected value. When it fails, the error shows both the received value and the expected value, so you know immediately where the mistake is. Loose assertions like "not empty" or "does not throw" pass for many wrong results.

Answer: C

Needed for what machines cannot evaluate: whether the experience feels natural, whether error messages are understandable, whether any part of the flow is confusing. And for exploratory testing — testers freely try scenarios no one has thought of.

Answer: C

So you can run a single test when debugging, run in parallel safely, and so a red test means the code is broken rather than another test leaving state behind. Interdependent tests create failures that only appear in one particular run order — the most time-consuming kind of bug to track down.

Answer: C

The risk is silently losing coverage: the pipeline is green so nobody notices, while that code area is no longer checked. If skipping is unavoidable, record the reason, assign an owner and a deadline, and have the pipeline report the number of skipped tests.

Answer: D

Because a short feedback loop decides whether tests actually get used. If they run in seconds while writing code, developers run them continuously; if they must wait ten minutes for the pipeline, they just push and hope.

Answer: B

Mock at the network layer (msw, nock, or intercepting fetch), not your own functions. That way, URL construction, headers, error handling, and response parsing still run for real — and that's exactly the part that tends to break.

Answer: C

No. Coverage measures which lines were executed, not what you asserted. A test that calls a function and checks nothing still gives 100% coverage. It's useful for finding what *isn't* tested, not for proving quality.

Answer: D

Investigate the cause. Four common sources: fixed-time waits (sleep 100), shared state between tests, execution order (one test depends on another), and time/timezone. Retry should only be a temporary measure while you fix it.

Answer: C

Prefer getByRole('button', { name: /send/i }). The recommended order is role → label → placeholder → text, with getByTestId as a last resort. Querying by role mirrors how users perceive the interface and also catches missing accessible names.

Answer: D

await screen.findByText(...) or await waitFor(() => expect(...)) — wait until the condition is met, not on a clock. Fast when the machine is fast, and doesn't break when CI is slower than the dev machine.

Answer: B

Wrap each test in a transaction and roll back: the data disappears on its own, no cleanup needed, and each test starts from a clean state. If the framework doesn't support it, use a separate schema per worker to run in parallel.

Answer: D

Prefer role + user-visible label (getByRole('button', { name: 'Thanh toán' })), and use data-testid where there's no stable label. Avoid XPath, CSS classes, and positional order.

Answer: A

No. Test through the public API — private is an implementation detail, and tests coupled to it will go red on every refactor even when the external behavior doesn't change. If a private function is complex enough that you want to test it separately, that's a sign it should become its own unit.

Answer: C

A large snapshot goes red on every small change — changing one class or adding a wrapper tag is a diff of hundreds of lines. People run -u to move on, and from then on the snapshot catches nothing.

Answer: A

Don't let the function read the clock itself: pass now in as a parameter (or inject a clock), then the test is just a pure function with fixed input. If you can't change the function signature, use a fake timer to freeze time.

Answer: A

Two things in parallel: run tests in parallel (split shards by file, each worker with its own DB) and split the layers — fast unit + integration tests as the merge gate, full e2e after merge or on a schedule.

Answer: B

Prioritize by cost of being wrong × complexity: billing, permissions, inventory, the payment flow, and anywhere with many conditional branches. Getters, simple mappers, or string-concatenation code can wait.

Answer: C

Use a factory/builder with valid defaults, and have tests override only the relevant part: makeUser({ role: 'admin' }). Tests are easy to read because only what matters is visible, and adding a required field only needs a fix in one place.

Answer: A

Three most important groups: authorization (not logged in, logged in but not the resource owner), bad input (missing fields, wrong types, out-of-range values), and nonexistent resources. That's where the vulnerabilities usually are.

Answer: A

Use renderHook from Testing Library, and wrap any state-changing operations in act(...). Without act, React will warn and you may read stale state.

Answer: B

Call the handler directly with a real Request (new Request(url, { method, body })) then assert the Response status and JSON. Don't mock req/res — the handler receives the exact object type the framework will provide.

Answer: B

Because error branches are rarely exercised in production, bugs there live long and only surface when the system is already failing — the worst possible time to discover another bug.

Answer: A

Create it inside the test using a factory: const user = await makeUser(); await makeOrders(user, 3). A self-contained test reads as its own input setup and doesn't break when the environment's seed data changes.

Answer: C

A measurable target: e.g. "1000 requests/second with p95 under 300ms and an error rate below 0.1%". Without concrete thresholds, the results are just a pile of numbers with no pass/fail conclusion.

Answer: D

Assert on what the user sees: the loading state appears, then the data shows up (await screen.findByText(...)), and when the API fails, an error message appears. Don't assert that the fetch function was called.

Answer: D

They should stay green. That is precisely the test of your test suite's quality: if a behaviour-preserving refactor turns tests red, the tests are coupled to implementation details (internal mocks, function names, DOM structure) instead of observable behaviour.

Answer: B

Environment-induced diffs: a different font, different antialiasing, a different screen ratio makes the diff go red even though the UI is unchanged. The fix is to capture screenshots in a fixed environment (a standardized container) and set a tolerance threshold.

Answer: D

Test when there are error-prone rules of your own: locale-specific currency formatting, plurals, rounding, truncating strings to a length. Don't re-test that a library works — that's testing someone else's code.

Answer: C

Log in once during setup, save the cookie/storageState, then have each test reload that state. You should still keep one test that goes through the real login form to protect that flow.

Answer: D

Write a characterization test at the outer layer (API, public function) to pin down the *current* behavior — even behavior that looks wrong. Once you have a safety net, fix the bug, and the old test tells you immediately if the fix breaks something else.

Answer: B

A test should describe one scenario. An if means it is merging two scenarios: when it goes red you don't know which branch is wrong. Split it into two clearly named tests, or use parameterized tests.

Answer: C

State leaking between tests: module-level variables, leftover data in the DB, mocks that were never reset, timers that were never cleaned up, or environment variables mutated by another test.

Answer: C

Use the framework's fake clock: replace the timer functions with a simulation, then advance time to the exact point needed. The test runs instantly, deterministically, and can check intermediate points — something impossible when waiting for real time.

Answer: B

Instead of checking a few concrete examples, you declare a property that always holds — for example "decoding an encoded value always returns the original" — and the tool generates hundreds of inputs to find a counterexample, then shrinks it to the simplest case.

Answer: A

Intercept at the network layer with a mock server running inside the test. That way all the request-building, header-setting, error-code handling, and response parsing still run for real — only the part going out to the network is replaced. Stubbing the API call directly would skip exactly the parts most likely to break.

Answer: A

Record the real response once and replay it in the test. This preserves the actual structure and keeps tests fast and deterministic. Alongside it, you need a periodic job that calls the real service to detect when it changes.

Answer: D

Wrap each test in a transaction and roll it back at the end. Faster than deleting tables repeatedly and guarantees a perfectly clean state. Note: this doesn't work when the code under test manages its own transactions or when the test spans multiple connections.

Answer: B

Every shared resource must be isolated per thread: database (separate schema), temp directories, network ports, environment variables, and config files. Missing one will produce random failures that only appear when running in parallel.

Answer: D

Focus on the boundaries: a last page that isn't full, an empty list, and a record count divisible by the page size. Equally important are duplicate values when sorting — without a tie-breaker, a record can appear on two pages or vanish.

Answer: C

Watch out for rounding: splitting a bill three ways and rounding each part can make the total drift by the smallest unit from the original amount. The test must assert that the parts sum to exactly the original amount, and also cover the rounding boundaries in between.

Answer: C

Call it twice with the same parameters and assert that system state changed only once: one record created, one charge deducted, one email sent. Checking the status code alone is not enough — both calls can return success.

Answer: D

Catches clear rule violations: images missing alt text, buttons missing labels, insufficient contrast, incorrect heading order, interactive elements not keyboard-accessible. This is the machine-checkable part, estimated to be only a fraction of real issues.

Answer: B

Three groups: missing translation keys in some language; text length breaking the UI when another language is significantly longer; and locale formatting — dates, decimals, currency, sort order.

Answer: A

Cover the error branches: file exceeds size limit, disallowed format (including when the extension says it's fine but the actual content differs), filename with special characters or path, and empty file. These are both error-handling branches and attack surfaces.

Answer: C

Assert at the system boundary: the email is enqueued with the correct recipient, correct template, and variables in the content filled in correctly. Actual sending belongs to an external service and should be checked separately by a scheduled test.

Answer: D

Two specific groups: field-level authorization — the same query can touch fields the caller is not allowed to see; and query complexity — a deeply nested query can create very large load. Both need separate tests because REST does not have these issues.

Answer: C

Three groups: on cache miss, fetch from the source and write to cache; on cache hit, do not call down to the source; and invalidation — after data changes, the next read must see the new value. The third group is where most cache bugs live.

Answer: D

Test the combinations that actually exist: the current state in production, and the state after enabling the new flag. The number of theoretical combinations grows exponentially, so covering all is impossible, but the number of real configurations currently running is very small.

Answer: C

Simulate the server side: return errors on the first two calls then succeed, and assert the client retries the right number of times and waits the right interval between attempts. Use a fake clock so you don't have to wait for real. Also cover the case where every attempt fails.

Answer: C

It gathers a page's selectors and actions into one place, so when the UI changes you only fix one file instead of dozens of tests. Tests are written at the business level — log in with this account, add that product — rather than at the level of manipulating elements.

Answer: C

Separate the message-handling logic from the connection: a function that takes a message and returns new state can be tested as a pure function. The connection part only needs a few high-level tests for reconnection, disconnect handling, and message ordering.

Answer: A

Render a child component that deliberately throws during render, then assert the fallback UI appears and the error-reporting function is called. Note that this mechanism does not catch errors in event handlers or in asynchronous code — a limitation to know when designing.

Answer: B

Use a seeded generator: each run picks a random seed, prints it, and when the test goes red you rerun with that exact seed to reproduce. That way you keep the exploratory benefit of random data while still being able to debug.

Answer: C

Cover two things: running against existing data — load realistic sample data, run the migration, and assert the data is transformed correctly; and the rollback path — run it backwards and assert the schema returns to its prior state.

Answer: A

Assert on ordering relationships: exact matches must rank above partial matches; newer posts must rank above older ones when relevance is comparable. Asserting on specific scores makes tests go red every time the algorithm is tuned.

Answer: A

Pick error-prone moments: DST transitions (with repeated and non-existent hours), half-hour or forty-five-minute offset zones, and midnight boundaries across different regions. Ordinary timestamps are almost always correct, so they detect nothing.

Answer: B

Assert on the data fed to the builder: line items, totals, and customer info are computed correctly. That is where the business logic lives. Comparing the output file's bytes depends on library version and embedded timestamps, so it is very brittle.

Answer: A

Set a very small limit in the test config — e.g. three calls per minute — then call four times and assert the fourth gets a 429. Use a fake clock to advance past the window and assert the limit resets at the right time.

Answer: D

Combine two levels: test each state transition — set up the input state, invoke one action, assert the new state; and one test for the full flow confirming the steps connect correctly. Most importantly, cover the invalid state transitions.

Answer: D

Focus on the local operation queue and syncing when connectivity returns: operations are stored correctly, sent up in the right order, and the case where data was modified by someone else while offline is handled.