Transcripted Summary
Now that we have seen the Generator agent build our clean automation test, let's talk about the last agent in the Playwright Test lifecycle: the Healer agent.
# Why a Healer Agent Exists
In a mature software development organization, a locator change should never catch an automation team by surprise. There should be awareness where developers communicate DOM updates throughout the department before code is deployed. However, let's be real — many engineering departments have not reached that level yet. When there is a small amount of communication, locators change and pipelines break, and then the automation team is playing detective. This is why some teams benefit from a healing agent.
In theory, when a test breaks due to a UI modification, the Healer agent steps in to operate as the missing communicator. It analyzes the failure, inspects the current state of the DOM, and figures out what changed.
# A Warning: Protect Your Domain Code
But as an SDET, I must issue a warning about using this tool. If you do not establish strict system prompts, working with any tool can trap you in the path of least resistance.
On one of my proof-of-concept demos, I caught the Healer agent taking a lazy shortcut. Instead of updating the page object file, it modified the application source code. I saw it update the HTML domain code itself just to force a quick test pass. It prioritized an immediate fix over integrity.
We must protect our domain code. In our framework, we are going to configure the Healer agent to operate as a communicator. We will command it not to automatically modify our application source code. Instead, it must execute the diagnostic check and insert a comment right above the affected element inside our page object file. That way it can alert us to the difference between our locator and the application DOM.
# Breaking a Locator on Purpose
Let me execute the test that was created by the Generator from the last session. So I'm going to go to the fourth test, verify successful submission test, copy relative path, and then bring up the terminal. I'm going to paste it, but I must also enter npx playwright test. Let's run.
Okay — I must also come here and change the backward slash to a forward slash. Now let's run. And here goes the browser. Bingo. It passed.
So in the page object file, let's go to the two methods that were created with the Generator agent — the select gender method and the check programming language method. And we see that they were created by AI from the last session's Generator agent, because we see the comment // Created By AI for both methods.
Now for the Healer agent, let's see which locator we're going to update. How about we update the submit button, line 26? I'm going to on purpose make it fail by adding an X at the end of submit. By adding the X at the end, let's see if the Healer agent catches it and gives us an update.
# The Guarded Diagnostic Prompt
So I'm going to bring up Claude Code and then paste this request. The request says: using the Playwright Test MCP Healer agent, analyze the runtime failure in our test suite. Compare the broken locator inside the page objects directory against the active application state after executing test 04 verify. (You know what — with Claude Code, you can use the @ symbol and then type in the file you need. Bingo, that's the test file.)
Strict compliance guardrails:
- Do not automatically rewrite or modify any locator variables or application values.
- Absolutely do not alter, touch, or modify our application domain HTML source files under any circumstances.
- Analyze the discrepancy and insert a clear alert comment,
// Created By AI, into our file right above the affected locator. Explain the exact difference between our localized selector and the DOM layout. Add your recommendation for the failure.
Now let's run.
Here goes the browser, and we see it got stuck at clicking the submit button. It clicked Java, but it has not clicked submit.
We see the summary. It says failure reproduced. And we see right here it shows the X at the end of submit. Locator was not changed. It added a // Created By AI alert comment. Next step for a human is to apply the one-character correction and rerun the test to confirm it passes. So it's telling us what we should do as the human in the loop.
At this point, let's go to the page object file. Bingo.
The Healer agent completed the diagnostic and operated strictly within our boundaries. It did not touch our domain code and did not overwrite our class variables. We still see the X at the end of our submit name. And here goes the Created By AI comment. And it provided this information on why it was a failure. And right here we see the X, and it shows the change from submit with the X to submit without the X. That's the recommendation.
So the agent inserted the comment explaining the locator. The objective was to operate as our communicator, leaving the final implementation control in our hands and not in the hands of AI.
# The Production Shift Ahead
Now we have walked through the complete Playwright Test MCP lifecycle from end to end: the Planner agent, the Generator agent, and the Healer agent. You now understand the default tool — but my day-to-day workflow looks different. I no longer use the Generator agent, and I have not used the Healer agent.
In our next session, we are stepping into station four, where I will show you the production shift. We will bypass the token-heavy inference of the Generator agent and deploy the power of the Playwright CLI to create highly deterministic automation files directly from documented functional test cases.
I will see you in station four.
