标签：#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 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 . Automated tests live wherever your team already puts them — tests/ , e2e/ , robot/ — in the same repository. 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 ]

A lot of Robot Framework projects still look like plain Selenium scripts with .robot file extensions. Someone imports webdriver , creates driver = webdriver.Chrome() , then calls find_element and send_keys in Python helpers. Robot Framework runs the suite, but readable keywords, shared libraries, and consistent waits never show up in the tests. If you already use Robot Framework with SeleniumLibrary , you do not need the raw WebDriver API. SeleniumLibrary gives you high-level keywords. The Page Object Model gives you structure. Together they keep tests short and UI changes localized. We published a small MIT template that shows the layout: rf-seleniumlibrary-pageobject-template . It targets Sauce Demo — clone it, run four tests, fork the folder structure. What breaks when you mix in raw WebDriver driver = webdriver . Chrome () driver . find_element ( By . ID , " user-name " ). send_keys ( " standard_user " ) driver . find_element ( By . ID , " password " ). send_keys ( " secret_sauce " ) driver . find_element ( By . ID , " login-button " ). click () Fine for a script. Painful in a growing suite. Locators spread across helpers and test files. Waits become time.sleep(2) in one place and missing in another. You end up maintaining SeleniumLibrary and a parallel WebDriver stack. CI fails on a Tuesday night and you are not sure which path opened the browser. Before and after Before After driver.find_element(...).send_keys(...) Login With Valid Credentials ${VALID_USER} ${VALID_PASSWORD} Locators in every file LoginLocators.USERNAME in one module Ad-hoc sleeps wait_until_element_is_visible in BasePage.click() Two browser stacks One SeleniumLibrary instance per suite Four layers Layer Job Example Locators Selectors per screen login_locators.py BasePage Shared waits and actions click() , enter_text() Page library Screen keywords LoginPage.login() Robot test Scenario only Inventory Should Be Visible Folder layout in the repo: resources/locators/ → selectors pages/ → Python pa