R&D Experiment: Can We Build Playwright-Style Agents for Selenium?

⚠️ Note: This project selenium_mcp_server – supportwithagents branch is experimental and not fully tested yet.
It is purely R&D — not a production-ready solution.

I also don’t work in a Selenium-based team. I built this out of curiosity to explore a question:
Can Playwright’s Test Agent system be recreated for Selenium, with support for multiple languages and frameworks?

🔍 Why I Did This

When Microsoft released Playwright v1.56 with the Planner, Generator & Healer agents, I was impressed.
Their agents don’t just read code — they explore a real browser, observe feedback, and make decisions.

Through this experiment, I now understand how Playwright Test Agents work in depth, including:

• How they use tools and browser feedback loops
• How test plans are generated using real observations
• Why AI + browser context creates smarter automation

The R&D Challenge

Could I recreate Playwright’s Test Agents using Selenium instead and make it work across multiple testing frameworks?

This is not:

• a team-driven project
• a mature Selenium toolkit
• a fully validated solution

This is:

• a proof-of-concept
• a learning experiment
• an exploration of AI + browser automation

🧠 What Was Built

Simple Workflow: “Test this website”

What You See vs What Happens Behind the Scenes

YOU TYPE: “Test this website “https://practiceautomatedtesting.com/"

↓

CLAUDE CODE THINKS: “User wants to test a website. I should use the planner agent to explore the site and create a test plan.”

↓

═══════════════════════════════════════════════════════════════ STEP 1: Start Planning Session ═══════════════════════════════════════════════════════════════

Claude Code calls: planner_setup_page ├─ Parameters: │ ├─ url: “https://practiceautomatedtesting.com” │ ├─ feature: “Website functionality” │ └─ exploration_depth: “quick” │ └─ What happens:

1. MCP server starts Chrome browser (if not running)
2. Browser navigates to https://practiceautomatedtesting.com
3. Page loads…
4. Server scans the entire page for interactive elements:
   • All buttons
   • All links
   • All input fields
   • All dropdowns
   • All clickable things
5. Creates a numbered list (e1, e2, e3…)
6. Sends back to Claude:

YOU SEE:

### Page state                                              
- Page URL: https://practiceautomatedtesting.com            
- Page Title: Example Domain                                
│ - Page Snapshot:                                            
```yaml                                                     
a "More information..." [ref=e1] [role=link]              
 - button "Login" [ref=e2] [role=button]                     
 - input "Email" [ref=e3]                                    
- input "Password" [ref=e4]                                 
- button "Submit" [ref=e5] [role=button]                    

═══════════════════════════════════════════════════════════════ STEP 2: Claude Explores the Website ═══════════════════════════════════════════════════════════════

Claude Code analyzes what it sees and decides: “I see a login form. Let me click around to understand the site.”

Claude calls: click_element ├─ Parameters: │ ├─ element: “More information link” │ └─ ref: “e1” │ └─ What happens:

1. Server looks up e1 → finds it’s the “More information” link
2. Server finds element on page (by text, ID, or CSS)
3. Clicks the link
4. Page navigates to new page
5. Server scans NEW page for elements
6. Sends back new snapshot

YOU SEE:

Clicked: More information link                              
                                                        
### Page state                                              
- Page URL: https://practiceautomatedtesting.com/info       
- Page Title: Information Page                              
- Page Snapshot:                                            
```yaml                                                     
- a "Home" [ref=e1]                                         
- a "Contact" [ref=e2]                                      
- h1 "About Us" [ref=e3] [level=1]                          

═══════════════════════════════════════════════════════════════ STEP 3: Claude Creates Test Scenarios ═══════════════════════════════════════════════════════════════

After exploring, Claude thinks: “I found:

• Login form
• Information page
• Contact page
• Navigation links

Let me create test scenarios for these.”

Claude calls: planner_save_plan ├─ Parameters: │ └─ plan_content: (markdown test plan) │ └─ Saves to: test-plans/website-functionality.plan.md

YOU SEE:

✅ Test plan created!                                        
                                                            
I've explored https://practiceautomatedtesting.com and c    
created a comprehensive test plan covering:                 
                                                           
1. Login functionality                                      
   - Valid credentials                                      
   - Invalid credentials                                    
   - Empty fields                                           
                                                             
2. Navigation                                               
   - Information page                                       
   - Contact page                                           
   - Back to home                                           
                                                            
3. Form validation                                          
   - Email format                                           
   - Password requirements                                  
                                                            
Test plan saved to:                                         
test-plans/website-functionality.plan.md                    
                                                            
Would you like me to generate executable tests from this?   

Example — Generated Test Plan

# Scenario: Add Item to Cart
Steps:
1. Navigate to /shopping
2. Click “Add to Cart”
3. Verify cart shows “1”
4. Open cart
5. Check product & price

Example — Selenium PyTest Output

def test_add_single_item(driver):
    driver.get("https://practiceautomatedtesting.com/shopping")

    add_btn = WebDriverWait(driver, 10).until(
        EC.element_to_be_clickable((By.CSS_SELECTOR, "[data-testid='add-cart-btn']"))
    )
    add_btn.click()

    cart_count = WebDriverWait(driver, 10).until(
        EC.presence_of_element_located((By.CSS_SELECTOR, ".cart-count"))
    )
    assert cart_count.text == "1"

🧭 What I Learned

Rebuilding this agents system taught me how Playwright agents work internally, especially:

• The tool feedback loop mechanism
• Structured prompts and task workflows
• Why real-time selector validation is critical
• How Markdown test plans are the perfect AI-friendly test layer

⚠️ Important Disclaimer

This project is not fully tested yet.
It may work well on some flows and fail on others — that’s expected in early R&D.
Right now, it should be seen as:

• an experiment
• an idea worth exploring
• a way to understand Playwright Agents by rebuilding them

🧠 Final Takeaway

Even if it never becomes a production tool, this experiment succeeded.

It showed that: ✔ Agent-driven testing can work in Selenium
✔ Browser feedback loops are powerful
✔ Playwright’s architecture can be adapted
✔ Multisupported scripts in various languages like Python, javascript, Robot Framework, Typescript, as long as it is selenium ✔ The best way to understand something — is to try building it yourself

if you want to experiment please check out this branch selenium_mcp_server – supportwithagents branch

R&D isn’t about finished tools. It’s about discovering what’s possible.

Instruction installation for claude code can be found in the repo (vscode en cursor support will be there shortly)