Question 1

How do you debug a failing test? Walk me through your steps.

Accepted Answer

My sequence: (1) read the error message and stack trace — an assertion error means the product differs, a TypeError means the test code is broken; (2) find the topmost stack line inside my own file; (3) with Playwright, open the trace viewer — it has a DOM snapshot, network requests and console per step, which often answers the question immediately; (4) if needed, set a breakpoint and step through with --debug; (5) re-run it to establish whether the failure is consistent or flaky. Worth closing with: the first question is always "is this a product bug or a test bug?" — because the answer completely changes the direction of the investigation.

Question 2

How do you narrow down where a test actually fails?

Accepted Answer

In a long scenario "it failed" says very little, so first I split the test into visible stages: test.step in Playwright, clearly named helper functions elsewhere. The report then tells me directly which stage broke. Inside that stage I bisect: add one assertion checking an intermediate state — that an element is visible before the click, or the status of an API response. That moves the failure from "something is wrong" to "this specific expectation was violated". Additional techniques: custom assertion messages, attaching intermediate data to the report, and a precondition assertion validating the test data upfront. The principle: a test should explain its own failure — a test you have to debug is already a poorly written test.

Question 3

What do you do with a test that fails in CI but cannot be reproduced locally?

Accepted Answer

First I extract everything from the artefacts: trace, video, screenshots, network log and console. The trace viewer usually shows the difference straight away — an element loaded late, a request returned 500, or the page was not in the expected state. Then I list the environment differences: timezone and locale, viewport and headless mode, machine speed (CI is typically slower, which exposes race conditions), the number of tests running in parallel, the data in the database. I reproduce those locally: TZ=UTC, the same viewport, more --workers, a CPU-limited container. If the cause still hides, I add diagnostics to the test and re-run it in CI — far faster than blind debugging. The real causes I find most often: data shared between tests, time-based waiting, and an un-awaited network request.

Question 4

console.log, a debugger, or the trace — when do you choose each?

Accepted Answer

console.log is for quickly checking one value: cheap, but the iteration is expensive (change the code, re-run the test each time) and leftovers end up committed. A debugger pays off when the problem reproduces locally and you need to see several variables at once — conditional breakpoints are especially strong inside long loops. The trace/report is for non-reproducible failures: the event already happened and you investigate it in hindsight, which is why keeping trace, video and screenshots on on-first-retry in CI is mandatory. My practical policy: logs are temporary and never committed; permanent diagnostics come from test.step, meaningful assertion messages and artefacts attached to the report — those work in CI and for teammates alike.

Tool	What for	Note
console.log	checking a simple value or the flow	unreadable for arrays of objects
console.table(arr, ['id','status'])	shows an array of objects as a table	ideal for inspecting API responses
console.dir(obj, { depth: null })	expands the full nested structure	Node truncates depth in a plain log
console.time / timeEnd	measures how long a step takes	for finding why a test is slow
breakpoint (VS Code)	pausing execution and seeing every variable	far faster than logging
Playwright trace viewer	DOM, network and console per step	the primary tool for a CI failure

Debugging techniques

📚 Sources and documentation