
test-framework-migration-skill
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 Selenium, Puppeteer to Playwright, Cypress to Playwright, or vice versa. Triggers on: "migrate", "convert", "port", "selenium to playwright", "playwright to selenium", "puppeteer to playwright", "cypress to playwright", "rewrite tests in", "switch from [framework] to [framework]".
- Installs
- 218
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/lambdatest/agent-skills --skill test-framework-migration-skill- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads test-framework-migration-skill automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
Test Framework Migration Skill
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 |
FAQ
What does the test-framework-migration-skill skill do?
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 Selenium, Puppeteer to Playwright, Cypress to Playwright, or vice versa. Triggers on: "migrate", "convert", "port", "selenium to playwright", "playwright to selenium", "puppeteer to playwright", "cypress to playwright", "rewrite tests in", "switch from [framework] to [framework]".
How do I install test-framework-migration-skill?
Run npx skills add https://github.com/lambdatest/agent-skills --skill test-framework-migration-skill in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/test-framework-migration-skill/ (personal) or .claude/skills/test-framework-migration-skill/ (project).
Which AI agents can use test-framework-migration-skill?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is test-framework-migration-skill safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains test-framework-migration-skill?
It is published by lambdatest in lambdatest/agent-skills. It has 218 recorded installs.
More from lambdatest/agent-skills
playwright-skill
lambdatest/agent-skills
Generates production-grade Playwright automation scripts and E2E tests in TypeScript, JavaScript, Python, Java, or C. Supports local execution and TestMu AI cloud across 3000+ browser/OS combinations and real mobile devices. Use when the user asks to write Playwright tests, automate browsers, run cross-browser tests, test on real devices, debug flaky tests, mock APIs, or do visual regression. Triggers on: "Playwright", "E2E test", "browser test", "run on cloud", "cross-browser", "TestMu", "LambdaTest", "test my app", "test on mobile", "real device".
vitest-skill
lambdatest/agent-skills
Open the skill to read its SKILL.md instructions.
appium-skill
lambdatest/agent-skills
Open the skill to read its SKILL.md instructions.
pytest-skill
lambdatest/agent-skills
Open the skill to read its SKILL.md instructions.
selenium-skill
lambdatest/agent-skills
Open the skill to read its SKILL.md instructions.
jest-skill
lambdatest/agent-skills
Open the skill to read its SKILL.md instructions.
Popular testing & qa skills
tdd
mattpocock/skills
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
grilling
mattpocock/skills
Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
migrate-to-shoehorn
mattpocock/skills
Migrate test files from as type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace as in tests, or needs partial test data.
run-train
lllllllama/rigorpilot-skills
Rigor Train skill for deep learning research repositories. Use when a documented or selected training command should be run conservatively for startup verification, short-run verification, full kickoff, or resume, with command, config, seed, log, checkpoint, status, and metric evidence written to standardized trainoutputs/. Do not use for environment setup, exploratory sweeps, speculative idea implementation, or end-to-end orchestration.
test-driven-development
obra/superpowers
Use when implementing any feature or bugfix, before writing implementation code
finishing-a-development-branch
obra/superpowers
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work