DEV Community

Weiwen Weng
Weiwen Weng

Posted on • Originally published at gitoza.com

Link Manual Test Cases to Playwright and Robot Specs

#testing #playwright #robotframework

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.

One repo, two layers of the same suite

  1. Manual cases are YAML files under .gitoza-lite/test/cases/ (VS Code / Cursor extension) or .gitoza/test/cases/ (Desktop app). The filename without .yaml is the case id.
  2. Automated tests live wherever your team already puts them — tests/, e2e/, robot/ — in the same repository.
  3. Traceability is a shared id: put that case id on the automation side as a tag (or name), and on the YAML side as automated: true plus a params pointer.

A PR can change the case, the Playwright spec, and the link in one review.

Step 1 — Draft manual cases in the IDE

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 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.
Enter fullscreen mode Exit fullscreen mode

If the file is AUTH-001.yaml, the case id is AUTH-001. That string is the join key for everything below.

Step 2 — Put the case id on the automation side

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):

import { test, expect } from "@playwright/test";

test("login with valid credentials", {
  tag: ["@AUTH-001", "@smoke"],
}, async ({ page }) => {
  // ...
});
Enter fullscreen mode Exit fullscreen mode

Robot Framework — use [Tags]:

*** Test Cases ***
Login With Valid Credentials
    [Tags]    AUTH-001    smoke
    Open Login Page
    Submit Valid Credentials
    Dashboard Should Be Visible
Enter fullscreen mode Exit fullscreen mode

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.

Step 3 — Flip 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.
Enter fullscreen mode Exit fullscreen mode

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.

Why Git beats a TMS link field

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."

A concrete loop

  1. Feature lands on a branch.
  2. Agent drafts or updates manual YAML under .gitoza-lite/test/cases/…/{CASE-ID}.yaml.
  3. Automation engineer (or the same agent) implements Playwright / Robot and tags the test with {CASE-ID}.
  4. Agent or script sets automated: true and params on the matching case.
  5. Manual testers execute what is still unautomated; Desktop dashboards can show automation rate when you use the full app.

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
Full post: gitoza.com/blog/ai-link-manual-automated-test-cases

Top comments (0)