Skip to content
Endform logo Endform logo Endform docs

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 conversation Why 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_start checkout test by file and title, paused before the failing assertion
debug_test_run inspect the Pay now button and visible form state
debug_test_run read saved-card requests and client-side errors
debug_test_run capture a screenshot of the paused checkout
debug_test_stop clean 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 conversation Why 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_start settings test declaration, paused at source line 84
debug_test_run list every dialog with visibility and ARIA details
debug_test_run inspect the duplicate dialog's DOM ancestry
debug_test_stop clean 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 conversation Why 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_start profile-menu test in the WebKit project
debug_test_run open the menu and inspect its accessible items
debug_test_run compare focus and element geometry after the click
debug_test_run try the keyboard interaction used by the component
debug_test_stop clean 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 conversation Check 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_start account settings test paused before its save assertion
debug_test_run perform the save and wait for the success toast
debug_test_run verify the persisted value through the page UI
debug_test_stop clean 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.