Question 1

How do you make a class testable? Explain with an example.

Accepted Answer

Build the answer around one principle: what can I substitute? Principle: I can write a test only if every outward-facing dependency of the class can be replaced. So dependencies must arrive through the constructor, not be created inside a method. Concrete example (always include one — dry theory sounds weak): "SessionService used to construct HttpClient() internally and call DateTime.now(). In a test we could neither cut the network nor freeze time, so the token-expiry test failed when it ran past midnight. We changed the constructor to SessionService(this._api, {DateTime Function() now = DateTime.now}): the default parameter meant production code did not change at all, while the test passes now: () => DateTime.utc(2026, 3, 14) and became fully deterministic." Rules to add: avoid static singletons (they destroy isolation), separate business logic from I/O (a pure function is the cheapest thing to test), and depend on an interface so a fake can be written. Balance note (a senior signal): not everything needs injecting — for value objects and pure utilities it is just boilerplate. The line I draw: anything that leaves the process or is non-deterministic gets injected.

Question 2

How do you test asynchronous code and streams in Dart?

Accepted Answer

Split it into three levels — that keeps the answer tight. Futures: make the test async and either await the result or use await expectLater(future, completion(equals(x))). For the failure path, throwsA(isA<FormatException>()). Streams: await expectLater(stream, emitsInOrder([...])), with combinators like emitsError, emitsDone, neverEmits, emitsThrough. Key detail: a single-subscription stream cannot be listened to twice — two expectLater calls on the same stream blow up; you need stream.asBroadcastStream() or a single emitsInOrder. The most common mistake (say this): the missing await. expectLater returns a Future; without awaiting it the test goes green before the check finishes. dart analyze catches it with unawaited_futures. Bonus — time-dependent code: for retry, debounce and timeout tests I avoid real Future.delayed, which makes tests slow and flaky. With package:fake_async I advance a virtual clock, so 30 seconds of retry logic is verified in milliseconds. Mentioning this usually closes the question in your favour.

Question 3

When do you use mocks and when not? What is over-mocking?

Accepted Answer

Start by pinning the terms (interviewers value it): a stub returns canned answers; a fake is a working simple implementation; a mock records calls that you then assert on. My default is a fake, because it keeps real behaviour: an in-memory repository genuinely stores and returns data, so the test checks what the code does, not how it calls things. A mock earns its place only when the interaction itself is the requirement: "on a successful payment the analytics event is sent exactly once", or "with a cold cache the API is hit once". Over-mocking is mocking every dependency until the test verifies only its own expectations instead of real behaviour. Symptoms: the test mirrors the internal call sequence; renaming a method breaks 40 tests although behaviour is unchanged; tests are green while the app is broken because the mock imitates the real API incorrectly. When to mock nothing: pure functions, value objects, a class's own private helpers. Substitute only what crosses a process boundary — network, files, clock, randomness, database.

Question 4

What does a coverage number show and what does it not? Would you gate CI on coverage?

Accepted Answer

This question probes your attitude to metrics — naming a number is the trap. What it shows: which lines executed during the test run. dart test --coverage=coverage, then LCOV via package:coverage, kept as a CI report. What it does not show: (1) whether those lines were verified — an assertion-free test can reach 100%; (2) which cases were missed — empty lists, nulls, boundaries, error paths; (3) whether the tests are meaningful — a test asserting wrong behaviour still produces coverage. Position on gating (make it clear and justified): an absolute gate ("85%") is harmful — teams start gaming it by testing getters while the critical logic stays uncovered. I prefer a differential approach: coverage of the lines changed in a PR must not drop, plus a separate minimum for critical modules. That points the metric somewhere useful. Strong close: "Low coverage always means there is a problem; high coverage means nothing has been proven yet."

Question 5

Tests pass locally but flake in CI. How do you investigate?

Accepted Answer

Give it structure: first reproduce, then cause categories, then the fix. 1. Reproduce: dart test --test-randomize-ordering-seed=random shuffles the order and exposes leakage between tests immediately. I note the failing seed and replay exactly that one. I also run with -j 1 to disable parallelism: if that changes the outcome, a shared resource is the cause. 2. Categories: Shared state — a mutable object in setUpAll, a global singleton, a static cache, a fixed temp-file name. Time — DateTime.now(), timezone (CI usually runs in UTC, the laptop does not), races with real Future.delayed. Order and parallelism — tests sharing a file or a port; dart test runs files in parallel. Resources — the CI machine is slower and a tight Timeout breaks. 3. Fix principle: adding a retry is not a fix, it is a cover-up. I inject time and randomness, drive virtual time with fake_async, give each test its own temp directory (deleted via addTearDown), and move shared state into setUp. Process detail: instead of ignoring a flaky test we quarantine it and file a ticket — one flaky test is enough to kill trust in the whole suite.

API / matcher	What it checks	Example
`equals(x)` (or just `x`)	`==` equality; for collections it compares element by element	`expect(cart.total, 500)`
`isA<T>()`	The type; can also check fields via `.having(...)`	`expect(e, isA<PaymentDeclined>().having((x) => x.code, 'code', '402'))`
`throwsA(matcher)`	That a function throws — the argument must be a closure, not a call	`expect(() => parse('x'), throwsA(isA<FormatException>()))`
`completion(matcher)`	That a Future completes successfully, and its value	`await expectLater(fetchAge(), completion(equals(42)))`
`emitsInOrder([...])`	The order of events a stream emits; combines with `emitsError`, `emitsDone`, `neverEmits`	`await expectLater(s, emitsInOrder([1, 2, emitsDone]))`
`predicate((x) => ...)`	An arbitrary condition — when no built-in matcher fits	`expect(user, predicate<User>((u) => u.age >= 18, 'is adult'))`
`closeTo(v, delta)`	A `double` comparison with tolerance — `0.1 + 0.2 == 0.3` is false	`expect(rate, closeTo(0.3, 1e-9))`
`expectLater(...)`	The Future-returning version of `expect` for async matchers — must be awaited	`await expectLater(stream, emits(1))`

Testing in Dart

📚 Sources and documentation