Debug tests with AI

After you connect the Endform MCP server, your coding agent can pause inside one Playwright test on Endform’s remote infrastructure. It can inspect the accessibility tree, run JavaScript with access to fixtures such as page, interact with the browser, and collect screenshots while the test remains paused.

Start from your project directory and identify the test you want to debug as precisely as possible. A test file and title are usually enough; add the Playwright project when the same test runs in multiple projects.

Example conversationWhy does this button never become enabled?

You

Debug the checkout test called “completes payment with a saved card”. It times out waiting for Pay now to become enabled. Find out what state the page is in at that point.

debug_test_startcheckout test by file and title, paused before the failing assertion

debug_test_runinspect the Pay now button and visible form state

debug_test_runread saved-card requests and client-side errors

debug_test_runcapture a screenshot of the paused checkout

debug_test_stopclean up the completed debug session

AI response

The button is disabled because the saved-card request completed with 401. The page is showing a visually hidden “Session expired” alert, and the card selector has no options. The screenshot confirms that the form otherwise rendered normally.

The test’s storage state is loaded, but its session cookie is scoped to www.example.test while this project uses checkout.example.test. I would fix the authentication setup so the cookie covers the checkout host. Waiting longer for the button will not resolve this failure.

Example conversationWhy can Playwright see two matching dialogs?

You

Debug settings.spec.ts at the assertion on line 84. Playwright says the dialog locator resolves to two elements, but I only see one dialog in the trace.

debug_test_startsettings test declaration, paused at source line 84

debug_test_runlist every dialog with visibility and ARIA details

debug_test_runinspect the duplicate dialog's DOM ancestry

debug_test_stopclean up the completed debug session

AI response

There are two dialogs in the DOM. The visible dialog is the current preferences modal. A second, hidden dialog remains mounted inside the previous route and has the same accessible name.

The trace emphasizes the visible UI, which is why the duplicate is easy to miss there. At the checkpoint, page.getByRole("dialog", { name: "Preferences" }) has a count of 2; one has aria-hidden="true" but is still matched by the current locator.

The product fix is to unmount the old route’s modal. If the hidden modal is intentional, scope the test to the visible modal rather than using .first(), which would make the test depend on DOM order.

Example conversationWhy does this fail only in WebKit?

You

The profile-menu test only fails in our WebKit project. Pause before it clicks the menu item and compare what is actually available.

debug_test_startprofile-menu test in the WebKit project

debug_test_runopen the menu and inspect its accessible items

debug_test_runcompare focus and element geometry after the click

debug_test_runtry the keyboard interaction used by the component

debug_test_stopclean up the completed debug session

AI response

The menu opens in WebKit, but focus stays on the trigger. The component’s requestAnimationFrame callback that focuses the first menu item runs after the test presses Enter, so the key event goes to the trigger and closes the menu again.

Waiting for the first menu item to be focused makes the interaction reliable in the paused session:

await expect(page.getByRole("menuitem").first()).toBeFocused();
await page.keyboard.press("Enter");

This is a timing difference exposed by WebKit rather than a missing locator. I would also consider fixing the component so it is ready for keyboard interaction as soon as it reports the menu as open.

Example conversationCheck a proposed fix in the live session

You

I think the failing assertion should wait for the success toast instead of the response. Try that in the paused test and tell me whether it proves the save completed.

debug_test_startaccount settings test paused before its save assertion

debug_test_runperform the save and wait for the success toast

debug_test_runverify the persisted value through the page UI

debug_test_stopclean up the completed debug session

AI response

Waiting for the toast succeeds, but it does not prove persistence: reloading the page restores the old value. The application shows the success toast before the update request has completed, and this attempt’s request then fails with 409.

Keep the response assertion or verify the saved value after a reload. The proposed wait would make the test pass while preserving the product bug.

Debug sessions select exactly one test and end automatically after 15 minutes. The agent should stop the session when it finishes. See the debugging tool reference for selection options and return values.