yoklainterview sim

QA / Test Automation Sd Test Doubles Mocking Interview Questions

75 verified QA / Test Automation Sd Test Doubles Mocking interview questions — solve with answers, learn from explanations, test yourself in a real simulation.

Try the real simulation →

Sample questions

Sd Test Doubles MockingDifficulty 1
In unit testing, what is a "mock" object primarily used for?
  • aStoring the application's production configuration values safely between each deploy
  • bReplacing the database with a slower but functionally more accurate copy
  • cVerifying that specific methods were called on it, with specific arguments
  • dFormatting the final test report after the entire suite finishes running
Explanation:A mock is a test double that records how it was called (which methods, how many times, with which arguments) so the test can assert on those interactions afterward — that's (c). The other options describe unrelated concerns like config storage or reporting.
Sd Test Doubles MockingDifficulty 1
What best describes a "stub" in the context of test doubles?
  • aAn object that records every single call, including its exact arguments and order, for later behavior verification
  • bAn object that returns predetermined canned answers to calls, without the test verifying how it was invoked
  • cA fully working alternative implementation used in place of the real one entirely, indefinitely
  • dAn object passed only to satisfy a parameter list, never actually used anywhere at all
Explanation:A stub supplies fixed, predetermined responses to calls so the code under test has something to work with, but the test doesn't assert on how the stub was called — that's (b). Recording calls for verification describes a mock/spy, not a stub.
Sd Test Doubles MockingDifficulty 1
A "fake" test double is best described as:
  • aA lightweight but genuinely working implementation, such as an in-memory repository instead of a real database
  • bAn object whose sole purpose is to record which methods were invoked
  • cAn object that always returns the exact same hardcoded value regardless of input, with no way to reconfigure it per test case
  • dA production dependency accessed over the real network during the test
Explanation:A fake has real, working behavior but takes a shortcut unsuitable for production — an in-memory repository is a classic example: it behaves like a real repository (store/query) without needing an actual database, which is (a).
Sd Test Doubles MockingDifficulty 1
What distinguishes a "spy" from a plain mock?
  • aA spy never allows any verification of calls made to it at all, unlike a mock
  • bA spy wraps a real object, letting behavior run while allowing verification
  • cA spy can only ever be used for testing network requests and nothing else whatsoever
  • dA spy always throws an exception when any of its methods is called, regardless of configuration
Explanation:A spy wraps a real object (partially or fully) so the actual implementation still executes, while also recording calls for later verification — a hybrid of real behavior plus observation, matching (b).
Sd Test Doubles MockingDifficulty 1
What is a "dummy" object in the test double vocabulary?
  • aAn object that records every method call and later lets the test verify each individual one of them
  • bAn object that simulates real business logic in a simplified, in-memory form for use across many different tests
  • cAn object passed to satisfy a method signature but never actually invoked or inspected by the test
  • dAn object that returns different canned values depending on exactly which arguments the test happens to pass in
Explanation:A dummy exists purely to fill a required parameter slot — the code under test may hold a reference to it, but the test never calls its methods or checks its state, matching (c). Recording/verifying calls describes a mock, not a dummy.
Sd Test Doubles MockingDifficulty 2
What is the key practical difference between using a mock and using a stub in a test?
  • aA mock can only be created with Mockito, while a stub can only be created with a completely separate framework such as Jest
  • bA stub is always slower to execute than a mock in the test suite, regardless of what either one is configured to do
  • cThere is no practical difference whatsoever; the terms are fully interchangeable in every context and every mocking framework ever built
  • dA mock's test asserts on the interactions it received, while a stub's test only checks the outcome produced from its canned data
Explanation:The core distinction is what the test asserts afterward: with a mock, the test verifies the interaction itself (e.g. verify(service).sendEmail(...)); with a stub, the test only checks the result the code under test produced using the stub's data — that's (d).

Test yourself against the 1500-question QA / Test Automation bank.

Start interview