agentleFS
redhat-developerredhat-developer/rhdh/.cursor/rules/e2e-coverage-imports.mdc

rhdh / rules

Cursor rule171 starsChanged 20 days agoApache-2.0View on GitHub

When creating or modifying Playwright spec files under e2e-tests/playwright/, always use the coverage-instrumented test and expect instead of importing directly from @playwright/test. The instrumented version is a drop-in replacement: describe, beforeAll, expect, locators, and all fixtures behave identically. When COLLECT_COVERAGE is unset (the default), the instrumented fixture is a no-op with zero overhead. If the spec creates its own BrowserContext / Page via browser.newContext(), also import and call the explicit helpers: See docs/coverage/e2e-rhdh.md for full details on the coverage infrastructure.

We split this e2e-coverage-imports.mdc into the rules it gives an agent

2 rules. About 0 are common, 0 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    When creating or modifying Playwright spec files under e2e-tests/playwright/, always use the coverage-instrumented test and expect instead …

    line 7
  2. Very specific:

    If the spec creates its own BrowserContext / Page via browser.newContext(), also import and call the explicit helpers:

    line 23

≈ “Common” is an estimate: at least 1 in 5 of the 6,350 Cursor rule files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
e2e-coverage-imports.mdc
---
globs: e2e-tests/playwright/**/*.spec.ts,e2e-tests/playwright/**/*.test.ts
---

# E2E Coverage: Use Instrumented Imports

When creating or modifying Playwright spec files under `e2e-tests/playwright/`, always use the coverage-instrumented `test` and `expect` instead of importing directly from `@playwright/test`.

## Import Rule

```typescript
// WRONG - bypasses coverage collection
import { test, expect } from "@playwright/test";

// CORRECT - uses the @support path alias (configured in e2e-tests/tsconfig.json)
import { test, expect } from "@support/coverage/test";
```

The instrumented version is a drop-in replacement: `describe`, `beforeAll`, `expect`, locators, and all fixtures behave identically. When `COLLECT_COVERAGE` is unset (the default), the instrumented fixture is a no-op with zero overhead.

## Specs with Custom Context

If the spec creates its own `BrowserContext` / `Page` via `browser.newContext()`, also import and call the explicit helpers:

```typescript
import { test, expect, startCoverageForPage, stopCoverageForPage } from "@support/coverage/test";

test("my test", async ({ browser }, testInfo) => {
  const context = await browser.newContext();
  const page = await context.newPage();
  await startCoverageForPage(page);
  try {
    // test body
  } finally {
    await stopCoverageForPage(page, testInfo);
    await context.close();
  }
});
```

## Reference

See `docs/coverage/e2e-rhdh.md` for full details on the coverage infrastructure.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.