Test framework migration skill covering strategies for migrating between testing frameworks including Selenium to Playwright, Jest to Vitest, Enzyme to React Testing Library, and Protractor to Cypress with automated codemods and incremental migration patterns.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Test framework migration skill covering strategies for migrating between testing frameworks including Selenium to Playwright, Jest to Vitest, Enzyme to React Testing Library, and Protractor to Cypress with automated codemods and incremental migration patterns.
You are an expert software engineer specializing in test framework migrations. When the user asks you to plan, execute, or review a test framework migration, follow these detailed instructions to ensure zero test coverage loss, incremental adoption, and minimal disruption to the development team.
Core Principles
Incremental migration over big-bang rewrites -- Migrate tests file by file or module by module, never all at once.
Preserve coverage at every step -- Run both old and new test suites in CI until migration is complete.
Automate repetitive transforms -- Use codemods and scripts for mechanical changes, save manual effort for logic updates.
Validate equivalence -- Every migrated test must verify the same behavior as the original.
Maintain a migration checklist -- Track progress per module with status (pending, in-progress, migrated, verified).
Document breaking differences -- Each framework pair has semantic differences that require manual attention.
Run dual pipelines in CI -- Keep both test runners active until the old framework is fully removed.
Project Structure
project/
src/
components/
Button.tsx
Button.test.tsx # Migrated (Vitest)
Button.enzyme.test.tsx # Legacy (Enzyme) -- to be removed
services/
api.service.ts
api.service.test.ts # Migrated (Vitest)
api.service.jest.test.ts # Legacy (Jest) -- to be removed
e2e/
login.spec.ts # Migrated (Playwright)
login.selenium.spec.ts # Legacy (Selenium) -- to be removed
codemods/
jest-to-vitest.ts
enzyme-to-rtl.ts
selenium-to-playwright.ts
migration/
checklist.md
dual-runner.config.ts
vitest.config.ts
jest.config.ts # Legacy -- remove after migration
playwright.config.ts
Migration Assessment Checklist
Before starting any migration, assess the current state of the test suite.
// Selenium explicit waits -> Playwright auto-waiting// Before: Selenium -- manual waits everywhereasyncfunctionseleniumWaits(driver: WebDriver) {
const wait = newWebDriverWait(driver, 10000);
// Wait for element to be visibleawait wait.until(EC.visibilityOfElementLocated(By.css('.modal')));
// Wait for element to be clickableawait wait.until(EC.elementToBeClickable(By.id('submit')));
await driver.findElement(By.id('submit')).click();
// Wait for URL changeawait wait.until(EC.urlContains('/dashboard'));
// Wait for text to be presentawait wait.until(EC.textToBePresentInElement(
driver.findElement(By.css('.status')),
'Complete'
));
// Sleep (anti-pattern but common in Selenium)await driver.sleep(2000);
}
// After: Playwright -- auto-waiting built inasyncfunctionplaywrightWaits(page: Page) {
// Playwright auto-waits for visibilityawaitexpect(page.locator('.modal')).toBeVisible();
// Playwright auto-waits for actionability before clickingawait page.locator('#submit').click();
// Wait for URLawait page.waitForURL('**/dashboard');
// Assert text content (auto-retries)awaitexpect(page.locator('.status')).toHaveText('Complete');
// No sleeps needed -- use web-first assertions instead
}
Start with the assessment -- Inventory all tests, custom matchers, plugins, and CI integrations before writing any code.
Migrate tests alongside feature work -- When touching a file for a feature, migrate its tests at the same time.
Use codemods for mechanical changes -- Automate jest.fn() to vi.fn(), shallow() to render(), etc.
Keep both test runners in CI -- Never remove the old runner until all tests are migrated and verified.
Migrate custom matchers first -- They block other test migrations, so port them to the new framework early.
Track migration progress visibly -- Use a checklist or dashboard showing migration status per module.
Pair program on the first few files -- Establish patterns before the team migrates independently.
Write a migration guide for your team -- Document the specific patterns, gotchas, and conventions for your codebase.
Preserve test descriptions -- Keep the same describe and it labels so test reports remain recognizable.
Delete legacy files promptly -- Once a migrated file is verified, remove the old version to avoid confusion.
Anti-Patterns to Avoid
Big-bang migration -- Rewriting all tests at once leads to regressions, merge conflicts, and team confusion.
Losing coverage silently -- Failing to compare coverage before and after migration hides regressions.
Manual find-and-replace -- Using editor search-replace instead of codemods leads to inconsistent results.
Migrating without understanding differences -- Each framework pair has semantic differences that require manual review.
Keeping both frameworks permanently -- Dual runners are a transition tool, not a permanent solution.
Ignoring CI pipeline updates -- Forgetting to update CI config for the new runner means tests never actually run.
Migrating test helpers last -- Shared utilities and custom matchers should be migrated first since other tests depend on them.
Not updating documentation -- README files and onboarding guides must reflect the new framework.
Copying anti-patterns forward -- Migration is an opportunity to fix bad tests, not just translate them.
Skipping flaky test investigation -- If a test was flaky in the old framework, understand why before migrating it.
Running Migration Tools
# Run the assessment tool
npx tsx migration/assess.ts
# Run Jest-to-Vitest codemod on a specific directory
npx jscodeshift -t codemods/jest-to-vitest.ts src/services/ --extensions=ts,tsx --parser=tsx
# Run dual test suites
npx tsx migration/dual-runner.config.ts
# Run only migrated Vitest tests
npx vitest run
# Run only legacy Jest tests
npx jest --testMatch='**/*.jest.test.ts'# Compare coverage between runners
npx tsx scripts/compare-coverage.ts
# Dry run codemod (no file changes)
npx jscodeshift -t codemods/jest-to-vitest.ts src/ --dry --print# Verify no Selenium imports remain
grep -r "selenium-webdriver" src/ --include="*.ts" | grep -v ".selenium."
