test-automationlisted

# Test Automation (Robot Framework first) Automate the **user-visible behaviour**, deterministically. A flaky suite is worse than none — it trains people to ignore red. The project's existing automation setup always wins; this is the baseline. ## Universal principles (any framework) - **Deterministic, never timing-based.** Use explicit waits for a condition (element visible/enabled, text present); **never fixed sleeps**. Flakiness is a bug to fix or quarantine with a tag — not to retry blindly. - **Stable selectors.** Prefer `data-testid`, roles/labels, or accessible names over brittle deep XPath/CSS tied to layout. - **Independent & idempotent tests.** No order dependence; each sets up and tears down its own state; safe to run in parallel and repeatedly. - **Assert observable outcomes**, not implementation detail. One clear reason to fail per test. - **Data-driven** for variations; keep test data synthetic (**never real PHI/PII** — HIPAA). - **Tag** for selection (smoke/regression/component); wire into **CI** so a failure fails the pipeline (non-zero exit) with artifacts. ## Robot Framework (preferred for acceptance/E2E here) - Structure: `*** Settings ***` (Library/Resource/Suite Setup-Teardown), `*** Variables ***`, `*** Keywords ***`, `*** Test Cases ***`. Keep test cases in **business language**; push mechanics into **high-level keywords** in `*.resource` files (keyword-driven = your page-object equivalent). - **Library:** prefer the **Browser library** (Playwright-ba