Red-day diagnosis: break it on purpose, then read it

Yesterday you learned to read a green run, and a suite earns its keep on the red ones, so today you engineer some reds with your own hands. The first question you will answer every working day with automation is: test bug or product bug. The failures look different, and today you learn their faces while you are calm.

Failure one: the test is lying

Open your page object and sabotage a locator, the way a redesign would:

// was: page.getByTestId('search-submit')
this.searchSubmit = page.getByTestId('search-btn');

Run the suite and read the failure, actually read it:

✘ verify that searching for jerk finds the Jerk Chicken Plate with its price (30.2s)

  Test timeout of 30000ms exceeded.
  Error: locator.click: Test timeout of 30000ms exceeded.
  Call log:
    - waiting for getByTestId('search-btn')

The error names the exact locator it waited for. Nothing about search being broken, nothing about jerk dishes; the test never got that far. A timeout on a locator that used to work almost always means the pointer is stale, not the product. Fix the locator back. Diagnosis time: under a minute, because the failure was specific and your locators live in one file. Notice also how many tests went red from one sabotaged line, and how one edit healed them all. That is the Day 7 structure paying off.

Failure two: the assertion disagrees

Now sabotage an expectation instead. In your search test, change the expected price to 6,900 JMD and run:

Error: expect(locator).toHaveText(expected)

  Expected string: "6,900 JMD"
  Received string: "6,800 JMD"

A completely different face. No timeout, no waiting: the test reached the behaviour, asked its question, and got an answer it did not like. Expected against received, side by side. When you see this shape, the product did something, and your job is to decide whether the expectation or the product is wrong. Here it is the expectation, because you just vandalised it. Fix it back.

The three questions, in order

Every red, same drill:

1. Did the test fail to reach the behaviour? Timeout on a locator or a wait: probably the test. Fix the pointer, or the wait.
2. Did it reach the behaviour, and the assertion is wrong or too strict? Also the test. Tighten it honestly, the Day 8 way.
3. Did it reach the behaviour, and the product genuinely did the wrong thing? File it, with the failure output as evidence.

Most reds are question one or two, which is humbling and useful to know. The discipline is asking in order, so that when question three arrives you trust your own answer.

Test bug or product bug is the first question of every red, and the failure shape usually answers it before you finish reading.

Do this today

Both sabotages, both fixes, reading each failure fully before touching anything. Then rerun the locator sabotage with —trace on and scrub the filmstrip to the exact moment the click gave up. Tomorrow the store itself hands you a red, and it will be the most valuable one in the course.