test-case-to-playwright ยท diff
git:20260807.4fb0cdd to git:20260909.e6cdd77
1 added, 1 removed. Audit A to A.
---
description: Convert Katalon True Platform/TestOps manual test cases, test suites, or requirement-linked cases into Playwright TypeScript automation. Use when you need to fetch/read Katalon Platform test cases and implement Playwright scripts, create or adapt a Playwright framework, apply Page Object Model and fixtures, or translate manual steps into meaningful automated test keywords. Written for the automation tester converting a manual case into code that fits an existing page-object layer.
alwaysApply: false
---
<!-- GENERATED by scripts/build-adapters.mjs from skills/. Do not edit by hand. -->
# Katalon Test Case To Playwright Script
Use this skill to turn Katalon Platform/TestOps test cases into maintainable Playwright TypeScript automation. Prefer existing project patterns when a Playwright framework already exists. Treat the human as a tool: ask concise questions whenever a required target, credential, repository, AUT detail, or test data value cannot be discovered safely.
## Workflow
```text
+-------------------+ --> +-------------------+ --> +---------------------+
| Resolve Katalon | | Read test cases | | Resolve framework |
+-------------------+ +-------------------+ +---------------------+
|
v
+-------------------+ <-- +-------------------+ <-- +---------------------+
| Verify scripts | | Write automation | | Map manual steps |
+-------------------+ +-------------------+ +---------------------+
```
## Katalon Source
Resolve the Katalon context before writing code:
- Use Katalon MCP tools when available to list projects, list repositories/Test Projects, find test suites, find test cases, and read each selected test case.
- If the user gives a test suite, read the suite and every included test case before generating scripts.
- If the user gives requirement keys, find requirement-linked cases first.
- If MCP tools are unavailable or authentication fails, ask the user for exported test cases, case URLs, case IDs, or the test case text.
- Preserve traceability by keeping Katalon case IDs or titles in test annotations, comments, tags, or test names according to the target framework's style.
Extract for each case:
- Title, priority, requirement links, folder/suite, preconditions, test data, manual steps, and expected results.
- AUT URL, user roles/accounts, environment, browser/device assumptions, and cleanup requirements.
- Ambiguous selectors or business data that require human input.
## Framework Resolution
Inspect the workspace before creating anything:
- Search with `rg --files` for `playwright.config.*`, `package.json`, `tests/`, `e2e/`, `fixtures/`, `pages/`, and existing `*.spec.ts` files.
- If a Playwright framework exists in the workspace, summarize the detected path, conventions, and intended files, then ask the user to confirm before modifying it.
- If multiple candidate frameworks exist, ask the user which one to use.
- If no Playwright framework exists, ask whether the user wants to provide a Git repository/path or wants the agent to create/copy a framework into a target directory.
- If the user does not provide a repository/path after that prompt and the current workspace is writable, initialize a Playwright TypeScript framework in the current workspace.
When initializing a new framework, use TypeScript and include:
- `playwright.config.ts`
- `tests/` for specs
- `pages/` for Page Object Model classes
- `fixtures/` for custom fixtures and shared test data
- meaningful helper methods that read like domain actions, not raw selector operations
Read `references/playwright-typescript.md` before scaffolding a new framework or making broad changes to an existing one.
## Automation Design
Translate manual Katalon steps into Playwright scripts using these rules:
- Use Page Object Model for page structure and domain actions.
- Use fixtures for authenticated users, test data, API setup, reusable pages, and environment URLs.
- Write spec names and test steps that remain understandable to a manual tester.
- Prefer stable user-facing locators: role, label, placeholder, text, test id. Avoid brittle CSS/XPath unless the app gives no better option.
- Convert manual expected results into assertions near the action that produces them.
- Keep one automated test aligned to one Katalon test case unless the existing framework groups scenarios differently.
- Do not silently invent credentials, URLs, product IDs, account state, or selectors. Ask the human or mark a small TODO only when the missing value cannot be discovered.
Use meaningful keywords in page objects and fixtures, for example:
```ts
await productCatalog.searchForPhone(testData.phoneName);
await productCatalog.expectPhoneVisible(testData.phoneName);
await cart.addVisibleProductToCart(testData.phoneName);
await checkout.expectOrderSummaryTotal(expectedTotal);
```
## Implementation Rules
- Follow the existing repository's naming, linting, folder, fixture, and assertion conventions when present.
- Keep generated code idiomatic TypeScript with explicit domain names and minimal comments.
- Store test data in the existing data fixture pattern; if none exists, create typed fixture data rather than scattering literals across specs.
- Add tags or annotations for Katalon case IDs when the framework supports it.
- Avoid changing unrelated framework config unless required for the requested tests.
- If the AUT must be inspected to identify selectors, use Browser/Playwright exploration and keep selectors stable.
- If live AUT access is blocked, implement the structure and mark only selector/test data gaps that require human input.
## Verification
After writing scripts:
- Run the narrowest available check: TypeScript compile, lint, Playwright list, or a targeted `npx playwright test`.
- If the test cannot run because credentials, AUT access, or dependencies are missing, report the exact blocker and what remains unverified.
- Report created/updated files, mapped Katalon cases, commands run, and any manual inputs still needed.
---
## Bundled references
_The reference material the skill points to is inlined below so this file is self-contained._
### references/playwright-typescript.md
# Playwright TypeScript Reference
## Framework Detection
Use these signals to detect an existing framework:
- `playwright.config.ts`, `playwright.config.js`, or `playwright.config.mts`
- `@playwright/test` in `package.json`
- spec files under `tests/`, `e2e/`, `specs/`, or feature folders
- existing `pages/`, `page-objects/`, `fixtures/`, `test-data/`, or `utils/`
- custom test exports such as `fixtures/base.ts`, `test.extend`, or `export const test`
When a framework exists, inspect a few representative specs, page objects, and fixtures before editing. Match imports, file naming, tag style, fixture names, and assertion style.
## New Framework Shape
For a new TypeScript framework, use a small structure:
```text
playwright.config.ts
tests/
<feature>.spec.ts
pages/
<page-name>.page.ts
fixtures/
test.ts
test-data.ts
```
- Prefer `npm init playwright@latest` or the repository's package manager equivalent. Choose TypeScript, install browser dependencies only when needed, and avoid overwriting existing application files.
+ Prefer `npm init playwright` or the repository's package manager equivalent. Choose TypeScript, install browser dependencies only when needed, and avoid overwriting existing application files.
## Page Object Model
Page objects should expose business actions and assertions:
```ts
import { expect, type Locator, type Page } from '@playwright/test';
export class ProductCatalogPage {
readonly page: Page;
readonly searchInput: Locator;
constructor(page: Page) {
this.page = page;
this.searchInput = page.getByRole('searchbox', { name: /search/i });
}
async goto(baseURL: string) {
await this.page.goto(baseURL);
}
async searchForPhone(phoneName: string) {
await this.searchInput.fill(phoneName);
await this.page.getByRole('button', { name: /search/i }).click();
}
async expectPhoneVisible(phoneName: string) {
await expect(this.page.getByText(phoneName, { exact: false })).toBeVisible();
}
}
```
Avoid methods named only after low-level mechanics such as `clickButton` or `fillInput` unless they are private helpers. Use names that reflect the Katalon manual step's intent.
## Fixtures
Use fixtures to centralize reusable pages, users, and test data:
```ts
import { test as base } from '@playwright/test';
import { ProductCatalogPage } from '../pages/product-catalog.page';
import { testData } from './test-data';
type Fixtures = {
productCatalog: ProductCatalogPage;
data: typeof testData;
};
export const test = base.extend<Fixtures>({
productCatalog: async ({ page }, use) => {
await use(new ProductCatalogPage(page));
},
data: async ({}, use) => {
await use(testData);
},
});
export { expect } from '@playwright/test';
```
## Spec Mapping
Keep Katalon traceability visible:
```ts
import { test, expect } from '../fixtures/test';
test.describe('Search and filter', () => {
test('TC-123 Verify phone price and stock search', async ({ productCatalog, data }, testInfo) => {
testInfo.annotations.push({ type: 'katalonCaseId', description: 'TC-123' });
await test.step('Open cellphone storefront', async () => {
await productCatalog.goto(data.baseURL);
});
await test.step('Search for an in-stock phone', async () => {
await productCatalog.searchForPhone(data.phones.inStock.name);
await productCatalog.expectPhoneVisible(data.phones.inStock.name);
});
});
});
```
Each `test.step` should correspond to a meaningful manual action or assertion group, not every tiny Playwright call.
## Human-As-Tool Questions
Ask the human when any of these are missing and cannot be discovered:
- target repository or directory
- permission to modify an existing framework
- AUT URL or environment
- credentials, roles, or setup data
- unique product/order/user records
- selector strategy when the UI cannot be inspected
- whether to scaffold a new framework or use a provided repository
Keep questions short and actionable. Ask only for required values needed to continue.