yoklainterview sim
ProgressHistory

Backend Testing Interview Questions

75 verified Backend Testing interview questions — solve with answers, learn from explanations, test yourself in a real simulation.

Try the real simulation →

Sample questions

TestingDifficulty 1
What does a unit test primarily verify?
  • aThat the whole application behaves correctly from the end user's perspective
  • bThat a small, isolated piece of logic behaves correctly on its own✓
  • cThat the application stays responsive under heavy load
  • dThat separate modules communicate with each other correctly
Explanation:A unit test targets the smallest testable piece of logic in isolation from external dependencies. Verifying modules working together (d) is the job of integration tests, and the end-user perspective (a) belongs to end-to-end tests.
TestingDifficulty 1
According to the test pyramid, why should a project have many unit tests but only a few end-to-end tests?
  • aBecause end-to-end tests find fewer bugs than unit tests do
  • bBecause unit tests are the only kind a CI server can run reliably
  • cBecause lower-level tests are faster, more stable, and cheaper to run and debug in bulk✓
  • dBecause integration tests become unnecessary once unit coverage is high
Explanation:The pyramid is about cost and feedback speed: unit tests run in milliseconds and pinpoint failures, while end-to-end tests are slow, brittle, and expensive to maintain in large numbers. It is not that e2e tests find fewer bugs (a) — a few of them remain essential for critical flows.
TestingDifficulty 2
counter = 0   // shared module-level variable

test "single increment" {
  increment()
  assert counter == 1
}

test "double increment" {
  increment()
  increment()
  assert counter == 3
}

Both tests pass when the file runs top to bottom. What is the problem here?
  • aThe tests share mutable state, so they fail when run alone, in a different order, or in parallel✓
  • bNothing — as long as the whole suite passes, the tests are fine
  • cThere is no issue in the code, because test runners reset module-level variables before each test
  • dThe two tests duplicate logic and should be merged into a single test
Explanation:The second test expects 3 only because the first test already incremented the shared counter; run alone it would see 2 and fail. Test runners do not magically reset your module state between tests (c) — each test must arrange its own starting state.
TestingDifficulty 2
What is the key difference between a unit test and an integration test?
  • aA unit test may freely use a real database as long as it tests a single function
  • bAn integration test always drives the system through its user interface
  • cUnit tests are written by developers, while integration tests belong to QA only
  • dA unit test isolates one piece of logic; an integration test verifies components working together✓
Explanation:Integration tests exercise real collaboration — for example service code against a real database — while unit tests replace such dependencies to isolate the logic. Touching a real database (a) already makes a test an integration test in most teams' vocabulary.
TestingDifficulty 2
You are writing a unit test for convertPrice(amount, currency), which internally calls a third-party HTTP exchange-rate API. How should the test handle that API call?
  • aCall the real API so the test stays as realistic as possible
  • bReplace the API client with a test double that returns a fixed exchange rate✓
  • cSkip testing this function, since it depends on an external service
  • dCache the first real API response on disk and reuse it in later runs
Explanation:A fixed-rate double makes the test fast, deterministic, and able to set up exact scenarios (e.g. a specific rate). Real calls (a) make the test slow and flaky and tie its outcome to live data; the cached-response variant (d) still depends on a real first call and hides what the test actually assumes.
TestingDifficulty 2
Many test frameworks let you define a setup block that runs before every single test in a file (pseudocode: setup { ... }). What is its purpose?
  • aTo rebuild a known, clean starting state before each test✓
  • bTo prepare shared data exactly once and reuse it across all tests for speed
  • cTo guarantee that the tests execute in the order they are declared
  • dTo automatically retry a failed test starting from a fresh state
Explanation:A per-test setup keeps tests independent: each one starts from the same known state. Preparing data once for all tests (b) describes a before-all style hook — convenient for expensive resources, but a classic source of cross-test coupling when the shared data is mutable.

By specialization

C#/.NET 450Go 450Java 450Node.js 450PHP 450Python 450

By seniority

Backend JuniorBackend MidBackend Senior

Other fields

FrontendFullstackDevOps / CloudAI EngineerDatabaseMobileSecurityQA / Test AutomationData EngineerGame DevelopmentML Engineer

Test yourself against the 3300-question Backend bank.

Start interview