/sap-testing

name: sap-testing
description: Entry point for the SAP UI test-automation environment. Explains project layout, the configured test folder, available tools, phase workflows, and bounded agent delegation. Use when the user asks about SAP UI testing, Playwright for SAP, writing tests for any ABAP report/transaction/process, generating test evidence docs, or mentions a SAP Testing folder.

SAP Testing — Overview

Non-negotiable execution gate

Every required phase step and artifact is a prerequisite for execution. The `abapfs_run_playwright_tests` tool verifies the full workflow state and **will reject the run** if any required item was skipped, deferred, left missing, stale, or unverified. Complete every requirement at the point specified by the relevant phase workflow; you cannot defer it and repair the omission at run time.

Why

This is production SAP for a real business. Every bug that ships costs money — wrong invoice, wrong stock movement, wrong customer charge, blown financial close. Test suites here are the last gate before code touches accounts, orders, or inventory. The goal is NOT to finish; the goal is to catch every bug before it ships. Cutting corners because the code is long, the sandbox is thin, or the task is tedious is exactly how a million-dollar defect reaches production. Speed is worthless if you miss the bug.

The available SAP Testing tools drive **Playwright** against SAP WebGUI. Specs use the bundled `SapSession`/`SapArtifacts` runtime through `@sap-testing/runtime`, and runs produce `.docx` evidence. There is no terminal, no `npm`, no `.env` — every action below is either a tool call or a normal file edit inside the configured test folder.

Where things live — two different places, on purpose

| Lives in | Contains | Editable by you? | | ------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | The **test folder** (`abapfs.testing.folder` setting — ask the user to run "ABAP FS: Enable SAP UI Testing Features" if unset) | `tests/<PROGRAM>/test-cases/*.md`, `test-scripts/*.spec.ts`, `test-results/**`, one managed `tsconfig.json` | Yes — this is a normal, git-trackable project folder. Read/write it with your normal file tools. | | **Bundled SAP Testing runtime** (available through `@sap-testing/runtime` and the tools below; not a workspace folder) | `SapSession`, `SapArtifacts`, `resolveTestData`, `buildFixture`, and the 10 tools below | No — its implementation is not available to file tools. See `helpers-reference` when a capability is missing. |

Everything for one program lives together under `tests/<PROGRAM>/` inside the test folder:

<test folder>/
├── tsconfig.json                (managed automatically by SAP Testing — never hand-edit)
├── recordings/                  User-assisted Playwright reference recordings; never runnable specs
└── tests/
    └── <PROGRAM_NAME>/          One folder per ABAP object under test
        ├── test-cases/          Phases 1–4 output — _flow.md + _units.md + _findings.md (P1) + _screens.md (P2) + TC-XXX.md + _index.md + _index.docx (P3) + TC-XXX.data.md (P4)
        ├── test-scripts/        Phase 6 output — TC-XXX.spec.ts (real @playwright/test specs)
        └── test-results/        Phase 5 (data.json) + Phase 7 (evidence) output — segregated per connectionId
            ├── <CONNECTION-ID>/              (e.g. DEV-100)
            │   └── <TC-ID>/                 per TC: screenshots, manifest.json, data.json, fixtures/
            └── <PROGRAM>-<CONNECTION-ID>-report.docx   ONE aggregated docx per (program, connectionId)

Rules:

• **All artifacts for a program are siblings** under `tests/<PROGRAM>/`. Never scatter `TC-001.md`, `TC-001.spec.ts`, and its screenshots.
• Raw user recordings live under `recordings/*.recording.ts`, outside `tests/`. They are temporary reference evidence, not phase outputs or runnable specs.
• Program folder name = **the name the user asked for** (report / tcode / class), uppercase, no spaces. When the user names a TRANSACTION, keep the folder as the tcode — do NOT rename it to the program the tcode runs. Phase 1 resolves the tcode to its executable object and records BOTH in `_flow.md` frontmatter (`target:` = the tcode/name, `resolvedProgram:` = the report/class actually analysed), so the mapping is explicit and no later phase re-derives it.
• The per-connection results folder is the `connectionId` in **UPPERCASE** (`test-results/<CONNECTION-ID>/`, e.g. `DEV-100`). The framework derives this folder by uppercasing the connectionId at run time, so any hand-written cache/results path MUST use the uppercase form — a lowercase folder is silently not found on a case-sensitive filesystem (Linux/macOS).
• Every `.spec.ts` you write imports from the fixed specifier `@sap-testing/runtime` — never a relative path (there is no `helpers/` folder in the test folder to point at). See `build-scripts` and `helpers-reference` for the full import convention and method reference.

Skills, tools, and agents are three different things — know which is which

Backticked names in these docs refer to one of three kinds of thing, and you interact with each differently. When a doc names one, it should say the kind ("the `X` skill/tool/agent"); if it doesn't, use this list to tell them apart:

• **Skills** (you LO