Link Manual Test Cases to Playwright and Robot Specs

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.

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. That is why automation coverage is usually a quarterly guess: the catalog and the specs never share an id. Put 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. .gitoza-lite/test/cases/ VS Code / Cursor extension or .gitoza/test/cases/ Desktop app . The .yaml is the case id tests/ , e2e/ , robot/ — in the same repository. automated: true plus a params pointer.A PR can change the case, the Playwright spec, and the link in one review. Open 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. Ask for several cases at once, not one shallow step. A useful prompt looks like: Read .gitoza-lite/test/cases/shopflow/auth/ for format. From ticket SHOP-184, draft three YAML cases happy path, invalid password, locked account . Filename = case id. Use tags auth and smoke where it fits. Save 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. The extension does not ship its own model. It keeps cases as plain YAML so whatever assistant you already use can read and write them. A minimal case: --- title: Login with valid credentials priority: high tags: smoke, auth status: active --- Steps 1. Open the login page 2. Enter valid credentials Expected result User is redirected to the dashboard. If the file is AUTH-001.yaml , the case id is AUTH-001 . That string is the join key for everything below. Before coverage can be marked, automation needs a handle that matches the YAML filename. Playwright — tags must start with @ or include the id in the test title : js import { test, expect } from "@playwright/test"; test "login with valid credentials", { tag: "@AUTH-001", "@smoke" , }, async { page } = { // ... } ; Robot Framework — use Tags : Test Cases Login With Valid Credentials Tags AUTH-001 smoke Open Login Page Submit Valid Credentials Dashboard Should Be Visible Same 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 @ so @AUTH-001 maps to AUTH-001.yaml . automated and fill params Once specs carry the case id, close the loop on the YAML side — with Cursor or a small script: Scan tests/ for Playwright tags matching case ids under .gitoza-lite/test/cases/ . For each hit, set automated: true on the YAML case and add params.playwright with the relative spec path. If a case id appears in tags but not in YAML, list the gaps. Do not set automated: true unless the tag and filename match after stripping @ . You end up with something like: --- title: Login with valid credentials tags: smoke, auth automated: true params: playwright: tests/auth/login.spec.ts --- Steps 1. Open the login page 2. Enter valid credentials Expected result User is redirected to the dashboard. For Robot, the same field under params might be robot: tests/auth/login.robot . Teams often add a custom key as well — auto tag: AUTH-001 or suite: 01 user authentication — so filters and scripts stay boring. params is a free key-value map; agree on a small schema in the repo README and stick to it. automated: true is the coverage flag. params is the pointer. Tags on the YAML side stay useful for smoke, priority, and feature filters — they do not have to duplicate the automation path. Treat agent output like any other PR: review git diff before merge. A wrong tag match that flips automated: true is worse than a missing link — catch it in review, or run the same rules in CI so chat is optional. In a vendor database, linking is usually a URL paste or a fragile title search. Agents cannot see the catalog unless you build API glue. In Git, the agent or a script reads cases and specs in one workspace, and git diff shows exactly which cases flipped to automated. Coverage is "scan tags ↔ case ids," not "update the spreadsheet after the sprint." .gitoza-lite/test/cases/…/{CASE-ID}.yaml . {CASE-ID} . automated: true and params on 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. Try it free VS Code extension : Gitoza on Marketplace https://marketplace.visualstudio.com/items?itemName=gitoza.gitoza-yaml-test-cases Full post: gitoza.com/blog/ai-link-manual-automated-test-cases https://gitoza.com/blog/ai-link-manual-automated-test-cases