Skip to content
LearnWithZavi

Make and check a change ยท Lesson 4

Test the Page and Fix a Small Bug with Codex

Report expected and actual behaviour, reproduce a bug and check that a focused fix works beyond the first click.

Tell Codex what you saw

Open the workshop page after your wording change. Press Show more details. The panel opens and the button says Hide more details. Press it again. In the starter version, the panel stays open.

That is a useful bug report because it has steps, an expected result and an actual result. "The button is broken" contains less evidence. A screenshot can help explain a visual problem, but a sequence of actions is often essential for an interaction problem.

A focused debugging request
The more-details button in the workshop practice page does not close the panel.

Steps: open the page, click "Show more details", then click "Hide more details".
Expected: the second click hides the panel, restores "Show more details" and sets aria-expanded to false.
Actual: the panel stays visible and aria-expanded stays true.

Reproduce or inspect this behaviour, explain the cause and fix only the toggle logic. Preserve the headline change and event facts.
Check the initial state, open, close and reopen. Use the keyboard too. Report actual checks and any you could not run.

Understand the cause in plain English

The starter click handler always sets the panel to visible and the expanded state to true. It never checks whether the panel is already open. Changing the button text alone would leave the behaviour broken.

A suitable fix reads the current state and switches it each time. For reference, this is one possible handler body using the starter's toggle and details variables:

One possible toggle fix โ€” inspect the state change
const expanded = toggle.getAttribute("aria-expanded") === "true";
details.hidden = expanded;
toggle.setAttribute("aria-expanded", String(!expanded));
toggle.textContent = expanded ? "Show more details" : "Hide more details";

This is a reference implementation, not a requirement to produce identical code. Judge the result by its behaviour and the project's constraints.

Check more than the first click

StepPanelButton textExpanded state
Fresh pageHiddenShow more detailsfalse
First activationVisibleHide more detailstrue
Second activationHiddenShow more detailsfalse
Third activationVisibleHide more detailstrue

Use Tab to reach the button, then Enter or Space to activate it. Confirm that focus remains usable and the same state changes occur. Also check the original See session details link and your new headline; the fix should preserve those parts.

If Codex says it cannot open a browser, that is a check not performed. Ask what it inspected, run the visible checks yourself and record the limitation. Do not turn a suggested test into a claim that the test passed.

Give the next piece of evidence

If the first repair fails, describe the exact remaining state. For example: "The second click now hides the panel, but the label still says Hide more details. Make the label match the collapsed state."

Keep the same starting page and repeat the same checks. Changing the test halfway through makes it harder to know whether the repair fixed the original problem. The course workbook includes this test record.

Checkpoint

Check the initial, open, closed and reopened states. Record whether pointer and keyboard activation both work, and whether the headline and event facts remain correct.

๐Ÿ“ Quiz

1 of 3

Swipe right if this answers the question correctly, left if it does not.

Which report gives Codex the most useful debugging evidence?

โ€œThe second click should close the panel, but it stays open; here are the stepsโ€

Is this the right answer?

Found this useful? Pass it on.