Question 1

What is mocking in tests, and when does it go wrong?

Accepted Answer

Replacing a real dependency with a **controlled stand-in**, so a test can run fast, deterministically, and without touching a network, database or clock. It is essential and it is **the most commonly overused technique in testing**.

**The vocabulary, which is used loosely and does have distinctions:**

**Dummy** — passed but never used.

**Stub** — returns canned answers.

**Spy** — a stub that also records how it was called.

**Mock** — pre-programmed with expectations, and **fails the test if they are not met**.

**Fake** — a real working implementation that is simpler, such as an in-memory repository.

**What mocking is genuinely for:** removing slowness and non-determinism, simulating failures that are hard to produce — timeouts, disk full, a 500 from a third party — and isolating the unit under test.

**Where it goes wrong, and these are the recurring failures:**

**Testing the mock instead of the code.** If the test asserts that a method was called with certain arguments, and the production behaviour is entirely defined by that call, the test verifies your restatement of the implementation. **It passes whether or not the system works.**

**Coupling to implementation.** Heavy mocking means any refactor that changes internal calls breaks tests without any behaviour changing — which trains people to distrust and delete tests.

**Mocks drifting from reality.** Your stub returns what you believe the API returns. When the real one changes, or always differed, **every test still passes** while production fails. This is the most dangerous failure because it is silent.

**Mocking what you do not own.** Mocking a third-party client encodes your assumptions about it. Better to wrap it in your own interface and mock that.

**Over-isolation**, where every collaborator is mocked and nothing is left to test.

**What to prefer:** **fakes over mocks** where a simple real implementation is possible; **contract tests** against the real dependency to catch drift; **test containers** for real databases, which are now cheap enough to be the default; and asserting on **outcomes rather than interactions** wherever the code allows.

Question 2

What is the difference between a unit test and an integration test?

Accepted Answer

A unit test exercises one piece of logic in isolation, replacing its collaborators with stand-ins. An integration test exercises several real components together, typically including something

Question 3

What is test-driven development, and does the evidence support it?

Accepted Answer

A practice of writing a failing test before the code that satisfies it, in a short cycle — red, green, refactor. The evidence for its claimed benefits is mixed and weaker than advocates suggest,

Question 4

What does code coverage actually tell you?

Accepted Answer

Which lines were executed while the tests ran — and nothing at all about whether those lines were checked, or whether the behaviour is correct. It is a measure of what was not tested, which is

Question 5

What is chaos engineering?

Accepted Answer

Deliberately injecting failure into a system to discover how it behaves — on the reasoning that failures will occur anyway, and it is better to discover the consequences during working hours than at

Question 6

What is dependency injection and why does it help?

Accepted Answer

Dependency injection means a component receives the things it depends on from outside, rather than constructing them itself. The contrast. Without it, a class creates its own collaborators: A

Question 7

Why do my tests pass locally but fail in continuous integration?

Accepted Answer

The gap is almost always something present on your machine and absent from the runner. Continuous integration starts from a clean environment every time, which is the point, and that clean start

Related Questions