{"slug": "link-manual-test-cases-to-playwright-and-robot-specs", "title": "Link Manual Test Cases to Playwright and Robot Specs", "summary": "A developer proposes linking manual test cases to Playwright and Robot Framework specs by storing both in the same Git repo and using stable YAML case IDs as join keys. The approach enables any IDE agent to match and update coverage without a custom AI product, keeping cases as plain YAML files that tools like Cursor or VS Code can read and write.", "body_md": "Most teams already keep Playwright or Robot Framework specs next to the product. Manual cases often live somewhere else — a spreadsheet, a cloud TMS, or a wiki page nobody updates after the first release.\n\nThat is why automation coverage is usually a quarterly guess: the catalog and the specs never share an id.\n\nPut both in the **same Git repo**, give every manual case a stable id, and linking becomes a text match. Any IDE agent can do that if the cases are files it can already see — no custom AI product inside a test tool.\n\n`.gitoza-lite/test/cases/`\n\n(VS Code / Cursor extension) or `.gitoza/test/cases/`\n\n(Desktop app). The `.yaml`\n\nis the case id`tests/`\n\n, `e2e/`\n\n, `robot/`\n\n— in the same repository.`automated: true`\n\nplus a `params`\n\npointer.A PR can change the case, the Playwright spec, and the link in one review.\n\nOpen the repo in Cursor or VS Code. Point the agent at a few existing case files so it learns your title style, tags, and step length. Then feed it a user story, a ticket, or a screenshot.\n\nAsk for several cases at once, not one shallow step. A useful prompt looks like:\n\nRead\n\n`.gitoza-lite/test/cases/shopflow/auth/`\n\nfor format. From ticket SHOP-184, draft three YAML cases (happy path, invalid password, locked account). Filename = case id. Use tags`auth`\n\nand`smoke`\n\nwhere it fits.\n\nSave the files under the suite folder. Then open the [Gitoza Lite](https://marketplace.visualstudio.com/items?itemName=gitoza.gitoza-yaml-test-cases) Test Repository tab to browse, edit, and — when you are ready — run them as a manual suite with Pass / Fail / Skip.\n\nThe extension does not ship its own model. It keeps cases as plain YAML so whatever assistant you already use can read and write them.\n\nA minimal case:\n\n```\n---\ntitle: Login with valid credentials\npriority: high\ntags: [smoke, auth]\nstatus: active\n---\n\n## Steps\n1. Open the login page\n2. Enter valid credentials\n\n## Expected result\nUser is redirected to the dashboard.\n```\n\nIf the file is `AUTH-001.yaml`\n\n, the case id is `AUTH-001`\n\n. That string is the join key for everything below.\n\nBefore coverage can be marked, automation needs a handle that matches the YAML filename.\n\n**Playwright** — tags must start with `@`\n\n(or include the id in the test title):\n\n``` js\nimport { test, expect } from \"@playwright/test\";\n\ntest(\"login with valid credentials\", {\n  tag: [\"@AUTH-001\", \"@smoke\"],\n}, async ({ page }) => {\n  // ...\n});\n```\n\n**Robot Framework** — use `[Tags]`\n\n:\n\n```\n*** Test Cases ***\nLogin With Valid Credentials\n    [Tags]    AUTH-001    smoke\n    Open Login Page\n    Submit Valid Credentials\n    Dashboard Should Be Visible\n```\n\nSame idea for other runners: one stable token that equals the case id. Prefer the id over a free-text title match — titles drift; filenames should not. When matching Playwright tags to YAML, strip the leading `@`\n\nso `@AUTH-001`\n\nmaps to `AUTH-001.yaml`\n\n.\n\n`automated`\n\nand fill `params`\n\nOnce specs carry the case id, close the loop on the YAML side — with Cursor or a small script:\n\nScan\n\n`tests/`\n\nfor Playwright tags matching case ids under`.gitoza-lite/test/cases/`\n\n. For each hit, set`automated: true`\n\non the YAML case and add`params.playwright`\n\nwith the relative spec path. If a case id appears in tags but not in YAML, list the gaps. Do not set`automated: true`\n\nunless the tag and filename match after stripping`@`\n\n.\n\nYou end up with something like:\n\n```\n---\ntitle: Login with valid credentials\ntags: [smoke, auth]\nautomated: true\nparams:\n  playwright: tests/auth/login.spec.ts\n---\n\n## Steps\n1. Open the login page\n2. Enter valid credentials\n\n## Expected result\nUser is redirected to the dashboard.\n```\n\nFor Robot, the same field under `params`\n\nmight be `robot: tests/auth/login.robot`\n\n. Teams often add a custom key as well — `auto_tag: AUTH-001`\n\nor `suite: 01_user_authentication`\n\n— so filters and scripts stay boring. `params`\n\nis a free key-value map; agree on a small schema in the repo README and stick to it.\n\n`automated: true`\n\nis the coverage flag. `params`\n\nis the pointer. Tags on the YAML side stay useful for smoke, priority, and feature filters — they do not have to duplicate the automation path.\n\nTreat agent output like any other PR: review `git diff`\n\nbefore merge. A wrong tag match that flips `automated: true`\n\nis worse than a missing link — catch it in review, or run the same rules in CI so chat is optional.\n\nIn a vendor database, linking is usually a URL paste or a fragile title search. Agents cannot see the catalog unless you build API glue.\n\nIn Git, the agent (or a script) reads cases and specs in one workspace, and `git diff`\n\nshows exactly which cases flipped to automated. Coverage is \"scan tags ↔ case ids,\" not \"update the spreadsheet after the sprint.\"\n\n`.gitoza-lite/test/cases/…/{CASE-ID}.yaml`\n\n.`{CASE-ID}`\n\n.`automated: true`\n\nand `params`\n\non the matching case.Start with one suite. Do not try to backfill five years of TestRail in a weekend. Ship the next feature with case + spec + link in the same PR.\n\n**Try it (free VS Code extension):** [Gitoza on Marketplace](https://marketplace.visualstudio.com/items?itemName=gitoza.gitoza-yaml-test-cases)\n\n**Full post:** [gitoza.com/blog/ai-link-manual-automated-test-cases](https://gitoza.com/blog/ai-link-manual-automated-test-cases)", "url": "https://wpnews.pro/news/link-manual-test-cases-to-playwright-and-robot-specs", "canonical_source": "https://dev.to/weiwen-weng/link-manual-yaml-cases-to-playwright-and-robot-specs-5782", "published_at": "2026-07-22 15:44:09+00:00", "updated_at": "2026-07-22 16:00:58.975683+00:00", "lang": "en", "topics": ["developer-tools"], "entities": ["Playwright", "Robot Framework", "Gitoza Lite", "VS Code", "Cursor"], "alternates": {"html": "https://wpnews.pro/news/link-manual-test-cases-to-playwright-and-robot-specs", "markdown": "https://wpnews.pro/news/link-manual-test-cases-to-playwright-and-robot-specs.md", "text": "https://wpnews.pro/news/link-manual-test-cases-to-playwright-and-robot-specs.txt", "jsonld": "https://wpnews.pro/news/link-manual-test-cases-to-playwright-and-robot-specs.jsonld"}}