Skip to content

feat(conformance): generate the adapter capability matrix from one declared source - #448

Open
vishnuv688 wants to merge 2 commits into
mainfrom
feat/402-capability-matrix
Open

vishnuv688 wants to merge 2 commits into
mainfrom
feat/402-capability-matrix

Conversation

@vishnuv688

Copy link
Copy Markdown
Member

What & why

Closes #402

The adapter capability tables were maintained by hand in three places (the README, CrossFrameworkSupport.md and MobileTesting.md on the docs site). They disagreed with each other, and two of them had no Python column, because a markdown table cannot notice that a fourth adapter exists.

The matrix is now an output. packages/conformance/src/capabilities.ts declares every capability once, with a cell for each of the four adapters (WebdriverIO, Selenium, Nightwatch, Python), and pnpm docs:capabilities renders the tables from it.

  • Every adapter, every row. Cells are typed as a full map over the conformance suite's adapter ids, so a fifth adapter fails typecheck until every row says what it does.
  • A reason is required. A partial or unsupported cell without a reason is a type error. Reasons render as footnotes, written from the code and the Known debt entries in CLAUDE.md.
  • Tested versus declared. A cell marked "tested" names the conformance rules that prove it, and validation rejects a rule that does not exist or that the adapter has a known gap against. Tested cells render as "✅ tested" with a legend, so they stay visibly distinct from declared ones.
  • Nothing can skip the matrix.
    • Every user-facing option must map to a capability row or say why it is not one. That covers the shared base, the WDIO service, Selenium and Nightwatch option types (checked at compile time against the real types) and Python's enable() keywords, pytest options and DEVTOOLS_* variables (checked by a test that parses the source with Python's ast).
    • Every conformance rule must back a tested cell or be listed as internal with a reason.
  • Rendering. pnpm docs:capabilities rewrites the content between <!-- capability-matrix:<table>:start --> and :end --> markers. The README now holds three generated tables: trace mode, live dashboard and mobile. --check writes nothing and exits 1 when anything is stale, and a test runs it against the README. --website <checkout> also rewrites the two docs-site pages; it checks every target first and writes nothing when a page is missing its markers.

The matrix has 33 rows. Correcting the old tables along the way:

  • Python is in every table.
  • Selenium and Nightwatch DOM time-travel and network are "with BiDi", where the README showed full support. Without BiDi the suite records known gaps for both.
  • Selenium assertion capture is partial (jest and chai expect() surface only failing matchers), and Selenium headless is Chrome only.
  • Cucumber nesting cells such as "Scenario→Step" carried no status mark and now render as partial with reasons.
  • New rows include network, failed commands, run controls, Preserve & Rerun, the dashboard and screenshot switches, Safari focus, network without BiDi, iOS and mobile browsers.

The PR template gains a "Capability matrix" checkbox, and CLAUDE.md documents the command and both coverage checks.

Type of change

  • Bugfix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Polish (an improvement to an existing feature)
  • Breaking change (existing behavior changes for users)
  • Documentation
  • Internal (build, CI, dependencies, tooling)

Packages touched

  • shared (types and contracts)
  • core (framework-agnostic capture/reporting)
  • elements (published element/snapshot API — @wdio/elements)
  • service (WebdriverIO adapter)
  • nightwatch-devtools (Nightwatch adapter)
  • selenium-devtools (Selenium adapter)
  • selenium-devtools-py (Selenium Python adapter)
  • backend (server)
  • app (UI)
  • script (page-injected runtime)
  • trace (Trace mode)

The code lives in packages/conformance, which is private and test-only, beside the adapter ids and rules it uses. It imports only the adapters' option types. No changeset, since no published package changes.

Notes for reviewers

  • Where it lives. capabilities.ts is the declaration. Validation is in capability-validation.ts, the option maps in capability-options.ts, rendering in render-capabilities.ts and the CLI in capability-matrix.ts.
  • Tested cells are conservative. A cell is "tested" only where a conformance rule covers it and the adapter has no known gap against it. That is DOM time-travel and network for WDIO and Python, plus failed commands, run controls, the one-row-per-command rules and metadata. Everything else is declared.
  • The internal rules are the six adapters-agree-* comparisons, which judge adapters against each other rather than any one adapter.
  • Checks proven. Adding an unmapped option to Selenium's DevToolsOptions failed pnpm typecheck, and adding a keyword to Python's enable() failed the coverage test. Both were reverted.
  • Docs site. The website pages need the markers inserted once. A follow-up webdriverio PR adds them and the generated tables, and rewrites the sentence on CrossFrameworkSupport.md that says Python is not in the table. Dry-run against a copy of the docs, the generator renders all 33 rows on that page and the 6 mobile rows on MobileTesting.md.
  • Results. pnpm test: 2846 passed. pnpm lint: 0 errors and no new warnings. pnpm typecheck, pnpm build and pnpm docs:capabilities --check are clean.

Screenshots / recordings

n/a (no UI change)

🤖 Generated with Claude Code

…clared source

Three hand-maintained tables disagreed and two had no Python column, because
a markdown table cannot notice that a fourth adapter exists. Capabilities are
now declared once with a cell per adapter id, a required reason for every
partial or unsupported cell, and conformance rules behind every cell marked
tested. Every user-facing option of the four adapters, Python's DEVTOOLS_*
variables included, and every conformance rule must map to a capability row
or say why it is not one, so a new option, rule or adapter cannot skip the
matrix. The README tables render from it and a test fails when they are stale.
@greptile-apps

greptile-apps Bot commented Oct 23, 2026 •

Copy link
Copy Markdown
Contributor

RetriggerView in GreptileConfidence Score: 5/5

[Low impact] The PR appears safe to merge; the latest changes address the previous finding without introducing a new issue.

Summary

Generates adapter capability tables from one declaration, with checks for adapter cells, option coverage, rule coverage, and stale README tables.

  • The conformance matrix accounts for adapter options and suite rules.
  • Support tables now come from one generated four-adapter matrix.

Reviews (2) · Last reviewed commit: "fix(conformance): mark metadata and run ..." · Reviewed by Greptile

Comment thread packages/conformance/src/capabilities.ts Outdated
Their rules check a precondition (metadata ahead of the first command, a
command behind every offered run control), not the tab's content or that
Run, Rerun and Run all work, so a tested mark promised more than the suite
proves.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Generate the adapter capability matrix instead of maintaining three by hand

1 participant