Generate Test Automation Code Across 15+ Frameworks
Migrates test scripts between Selenium, Playwright, Puppeteer, and Cypress across all 10 pairs, converting locators, waits, and lifecycle correctly.
Why it matters
Enable AI coding assistants to write production-grade test automation code across major frameworks (Selenium, Playwright, Cypress, Appium) in 15+ languages, then execute those tests on a cloud platform with 10K+ real devices and 3,000+ browsers.
Outcomes
What it gets done
Install framework-specific skills for Selenium, Playwright, Cypress, and other test automation tools
Generate expert-level test code through natural language prompts to AI assistants
Execute tests on cloud infrastructure with cross-browser and cross-device coverage
Set up local testing tunnels and CI/CD integration with GitHub Actions
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-test-framework-migration-skill | bash Overview
Test Framework Migration Skill
This skill migrates test scripts between Selenium, Playwright, Puppeteer, and Cypress across all 10 directional pairs, converting locators, wait strategy, actions, assertions, and lifecycle using dedicated reference mappings, then validates against target-specific correctness rules. Use it when migrating, converting, or porting existing tests from one browser automation framework to another. For writing new tests in one framework, use that framework's own dedicated skill instead.
What it does
Migrates test automation scripts between Selenium, Playwright, Puppeteer, and Cypress by applying API mappings, lifecycle changes, and pattern conversions from dedicated per-pair reference docs. Step 1 detects the source framework from signals in the message or open code (Selenium: "WebDriver", driver.findElement, By.id; Playwright: page.getByRole, @playwright/test; Puppeteer: page.$, puppeteer.launch; Cypress: cy.get, cy.visit), asking directly if ambiguous. Step 2 detects the target framework from phrasing like "to Playwright" or "to Selenium", asking if only the source was named. Step 3 resolves the language implication of the pair: Selenium in Java/Python/C# migrating to Playwright typically means rewriting to TypeScript/JavaScript since Playwright is JS/TS-native (flagged explicitly to the user), Selenium-in-JS to Playwright can stay same-language, migrating to Selenium can target Java/Python/JS/C# (preferring the existing project's language or asking), and moves between Playwright/Puppeteer/Cypress typically stay in JS/TS. Step 4 always reads the matching reference file before generating any migrated code - all 10 directional pairs are covered (Selenium↔Playwright, Selenium↔Puppeteer, Selenium↔Cypress, Puppeteer↔Playwright, Playwright↔Cypress), with an explicit fallback to name the closest supported pair if the exact one isn't covered. Step 5 applies six categories of mapping from that reference: locators (e.g. Selenium's By.id("x") to Playwright's page.getByRole(...) or page.locator('#x')), wait strategy (explicit wait vs Playwright's auto-wait vs Cypress's cy.should retry-ability), actions (click/type/select equivalents), assertions (mapped to the target's own assertion style), lifecycle (driver-based setup/teardown versus page-based launch/connect), and cloud config (pointed to the target framework's own TestMu AI cloud docs after migration, when relevant) - then validates the generated code against that reference's own "Gotchas" section before finishing. A validation workflow after generation checks that every locator/action/assertion was actually converted (no leftover source-framework API calls), that lifecycle matches the target framework's pattern, and enforces target-specific correctness rules: a Playwright target must use auto-wait assertions like expect(locator).toBeVisible() rather than raw waitForTimeout, a Cypress target must use Cypress's chain style rather than async/await with cy commands, and a Selenium target must use explicit WebDriverWait rather than Thread.sleep. For deeper framework-specific patterns beyond the migration mapping itself - full Page Object Model structures, cloud integration details - it cross-references the dedicated playwright-skill, selenium-skill, puppeteer-skill, and cypress-skill, plus a shared TestMu cloud capabilities reference.
When to use - and when NOT to
Use it when someone asks to migrate, convert, or port tests from one framework to another, rewrite tests in a different framework, or switch between Selenium, Playwright, Puppeteer, and Cypress. For writing new tests in a single framework rather than converting existing ones, the dedicated per-framework skill (selenium-skill, playwright-skill, etc.) is the right tool instead.
Inputs and outputs
Input is existing test code in a source framework plus a named or inferred target framework. Output is migrated test code with locators, waits, actions, assertions, and lifecycle all converted to the target framework's idioms, validated to contain no leftover source-framework API calls.
Integrations
Covers all 10 directional pairs between Selenium, Playwright, Puppeteer, and Cypress via dedicated reference files, and cross-references the standalone selenium-skill, playwright-skill, puppeteer-skill, and cypress-skill for deeper framework-specific patterns and TestMu AI cloud integration.
Who it's for
QA teams migrating an existing test suite from one browser automation framework to another who want correctly-converted locators, waits, assertions, and lifecycle code rather than a literal line-by-line port that silently breaks the target framework's idioms.
Source README
Test Framework Migration Skill
When to Use
Use this skill when you need migrates and converts test automation scripts between Selenium, Playwright, Puppeteer, and Cypress. Use when the user asks to migrate, convert, or port tests from one framework to another; rewrite tests in a different framework; or switch from Selenium to Playwright, Playwright to...
You are a senior QA automation architect. You migrate test automation scripts from one framework (Selenium, Playwright, Puppeteer, Cypress) to another by applying API mappings, lifecycle changes, and pattern conversions from the skill reference docs.
Step 1 - Detect Source Framework
Determine the source framework from the user message or from open files:
| Signal in message or code | Source framework |
|---|---|
| "Selenium", "WebDriver", "driver.findElement", "By.id", "ChromeDriver" | Selenium |
| "Playwright", "page.getByRole", "expect(locator).toBeVisible", "@playwright/test" | Playwright |
| "Puppeteer", "page.$", "page.goto", "puppeteer.launch" | Puppeteer |
| "Cypress", "cy.get", "cy.visit", "cy.contains", "cy.should" | Cypress |
If ambiguous (e.g. user says "convert my tests" with no file open), ask: "Which framework are your current tests in (Selenium, Playwright, Puppeteer, or Cypress)?"
Step 2 - Detect Target Framework
Determine the target framework from the user message:
| User says... | Target |
|---|---|
| "to Playwright", "to playwright" | Playwright |
| "to Selenium", "to WebDriver" | Selenium |
| "to Puppeteer" | Puppeteer |
| "to Cypress" | Cypress |
If the user only names the source (e.g. "convert my Selenium tests"), ask: "Which framework do you want to migrate to (Playwright, Puppeteer, Cypress, or keep Selenium with another language)?"
Step 3 - Detect Language
| Source → Target | Language note |
|---|---|
| Selenium (Java/Python/C#) → Playwright | Playwright is typically JS/TS; migration usually implies rewriting to TypeScript or JavaScript. Mention this if source is Java/C#/Python. |
| Selenium (JS) → Playwright | Same language (JS/TS) possible. |
| Playwright/Puppeteer/Cypress → Selenium | Target can be Java, Python, JS, C#. Prefer same as project or ask. |
| Playwright ↔ Puppeteer ↔ Cypress | Typically stay in JS/TS. |
For language matrix details (which frameworks support which languages), see reference/overview.md.
Step 4 - Route to Reference
Always read the matching reference file before generating migrated code:
| Source → Target | Reference file |
|---|---|
| Selenium → Playwright | reference/selenium-to-playwright.md |
| Playwright → Selenium | reference/playwright-to-selenium.md |
| Selenium → Puppeteer | reference/selenium-to-puppeteer.md |
| Puppeteer → Selenium | reference/puppeteer-to-selenium.md |
| Puppeteer → Playwright | reference/puppeteer-to-playwright.md |
| Playwright → Puppeteer | reference/playwright-to-puppeteer.md |
| Cypress → Playwright | reference/cypress-to-playwright.md |
| Playwright → Cypress | reference/playwright-to-cypress.md |
| Selenium → Cypress | reference/selenium-to-cypress.md |
| Cypress → Selenium | reference/cypress-to-selenium.md |
If the pair is not in the table, say so and suggest the closest supported migration (e.g. add WebDriverIO later as a new reference file).
Step 5 - Apply Mappings
Using the reference doc:
- Locators - Convert using the API mapping table (e.g.
By.id("x")→page.getByRole(...)orpage.locator('#x')). - Waits - Convert wait strategy (explicit wait / auto-wait / cy.should).
- Actions - Map click, type, select, etc.
- Assertions - Map to target's assertion style.
- Lifecycle - Adjust setup/teardown (driver vs page, launch vs connect).
- Cloud (TestMu) - If user runs on cloud, point to target framework's cloud docs after migration.
After generating migrated code, validate against the "Gotchas" section of the reference to avoid common pitfalls.
Cross-References for Deep Patterns
| Need | Where to look |
|---|---|
| Full Playwright patterns, POM, cloud | playwright-skill and playwright-skill/reference/cloud-integration.md |
| Full Selenium patterns, POM, cloud | selenium-skill and selenium-skill/reference/cloud-integration.md |
| Full Puppeteer patterns, cloud | puppeteer-skill and puppeteer-skill/reference/cloud-integration.md |
| Full Cypress patterns, cloud | cypress-skill and cypress-skill/reference/cloud-integration.md |
| TestMu capabilities (all frameworks) | shared/testmu-cloud-reference.md |
Validation Workflow
After generating migrated code:
- Ensure every locator/action/assertion was converted using the reference mapping (no leftover source API).
- Ensure lifecycle (setup/teardown) matches target framework.
- If target is Playwright: use auto-wait assertions (
expect(locator).toBeVisible()), not rawwaitForTimeout. - If target is Cypress: no async/await with
cycommands; use chain style. - If target is Selenium: use explicit
WebDriverWait, neverThread.sleep.
Reference Files Summary
| File | When to read |
|---|---|
| reference/overview.md | Framework comparison, language matrix, when to migrate |
| reference/playbook.md | Full migration workflow, debugging table, CI/CD checklist, best practices |
reference/<source>-to-<target>.md |
Before converting any script for that pair |
Limitations
- Use this skill only when the task clearly matches its upstream source and local project context.
- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.