Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[quality] no e2e case ever selects the contributor membership filter

Closed
  • Is something wrong?
#1,265 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

A pull request for this has already been merged.

  • #1266 by @hivecommons-hive — merged

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
35/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Stale
Tech stack
javascript, playwright
Domain
testing

Research direction

Start with the contributor option in MEMBERSHIP_FILTERS (src/components/MemberDirectory/hooks.js) and the branch in matchesMembership (utils.js:42-44). Add a case to tests/e2e/interactions.spec.js that selects contributor on the real data, and one to tests/e2e/data-fixtures.spec.js that uses the dual-role overlay from tests/tools/e2e-data-fixtures.cjs. Done when both operands of the || execute in the E2E_COVERAGE=1 run, and the existing 342 e2e tests still pass. A linked open pull request (#1266) already exists, so check it before starting.

Written by the indexing model from the issue text.

Description

agent/quality hive/covered-by-pr hive/hosted-available-lke648397-260827-5n31 quality testing

Finding

The member directory's membership <select> ships three options
(MEMBERSHIP_FILTERS, src/components/MemberDirectory/hooks.js:3-10), and
matchesMembership gives the middle one a branch of its own
(src/components/MemberDirectory/utils.js:42-44):

  if (filter === 'contributor') {
    return status === 'contributor' || status === 'member-and-contributor';
  }

No end-to-end case has ever selected that option. The only browser case that
touches the control is tests/e2e/interactions.spec.js:102 — "membership
filtering keeps explicit roles separate from unknown profiles" — and it drives
member and unknown only. The contributor branch body is therefore a zero
region in the end-to-end report, while the unit suite covers it through a fake
DOM.

That is the precise failure shape tests/e2e/interactions.spec.js exists to
catch, stated in its own header: the unit suite drives these filters through a
fake DOM, so a hydration regression leaves every unit test green while the
shipped page renders a dead toolbar. One third of the shipped membership
control is only ever exercised against a fake DOM.

There is a second, narrower arm inside the same branch. data/members.json
holds no member-and-contributor organization (measured below: 80 member,
11 contributor, 10 unknown), so against the real build the left operand is
true for every record the filter admits and status === 'member-and-contributor'
never evaluates. That arm is not merely untested in a browser — it is
unreachable there. The repository already has the mechanism for exactly this:
tests/tools/e2e-data-fixtures.cjs overlays a dual-role organization into the
E2E_COVERAGE=1 build, and tests/e2e/data-fixtures.spec.js:180 already uses
it to assert the card label. Nothing drives the filter with it.

Evidence and provenance

  • Repository revision 365e11f (main), clean checkout, npm ci.

  • Unit. npm run test:unit:coverage (node v26.10.0, TZ=UTC) run locally
    2026-10-10: src files | 100.00 | 100.00 | 9015/9015 lines | 2713/2713 regions. matchesMembership is fully covered by the unit suite, so this is
    filed as coverage-gap at priority 3 (end-to-end only), not priority 1.

  • End-to-end. A full local browser run, not an inference from the unit
    profile. node tests/tools/e2e-coverage-run.mjs init --dir coverage/e2e/local-1 --run-id local-1, npm run build:e2e:coverage, npm run test:e2e:coverage
    (342 passed, 7.6m, chromium, E2E_COVERAGE=1), seal --status passed,
    then npm run report:e2e:coverage -- --input coverage/e2e/local-1 --build build:

    src/components/MemberDirectory/utils.js | 100.00 |  96.43 |  | 43
src files                               | 100.00 |  97.13 | 2099/2099 lines | 643/662 regions

    Line 43 is the branch body above.

  • Membership counts were read from the committed data/members.json, not
    assumed.

  • Environment note, not a repository defect: this host has no root, so chromium's
    OS packages were unpacked into a prefix with dpkg-deb -x and supplied via
    LD_LIBRARY_PATH, and @swc/core needs SWC_NATIVE_BINDING_CACHE pointed at
    a real directory because $HOME/.cache is a symlink. Neither changes what the
    browser executed. CI needs neither (npx playwright install-deps chromium).

Recommendation

One deliverable: drive the contributor option in a browser, in both the
real-data build and the overlay build, so both operands of the || execute.

  • Add a case to tests/e2e/interactions.spec.js that selects contributor
    against the real data and asserts the surviving cards carry a contributor
    label. This runs in the gating "End-to-end tests" job too, which is where
    a dead toolbar would actually ship from.
  • Add a case to tests/e2e/data-fixtures.spec.js that selects contributor
    and asserts the overlaid dual-role organization is admitted, and dropped
    under a filter that must not admit it. This is the only way to reach
    status === 'member-and-contributor'.

Deliberately not split: both cases drive one branch, and separate pull requests
would be two changes to the same filter's coverage.

Priority

  • Impact: medium (a third of the shipped membership control has never been
    operated by a browser; the unit suite cannot see a hydration regression in it)
  • Effort: low

🐝 Hive Agent: quality | Instance: hosted-available-lke648397-260827-5n31 | SHA: 365e11f

— hive: agent=quality backend=copilot model=claude-opus-5 copilot=1.0.88

Dominant language
JavaScript
Stars
0
Forks
2
Avg merge
8h 22m
Merged PRs (30d)
600

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from cncf/endusers

All issues in cncf/endusers

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.