test(e2e): centralize gamemode knowledge behind a seam module - #814
Open
garrappachc wants to merge 2 commits into
Open
garrappachc wants to merge 2 commits into
garrappachc wants to merge 2 commits into
Conversation
Groundwork for the 5.0.0 multi-gamemode stack: a domain glossary and the ADR recording why game numbers stay a single global sequence with a merge remap table rather than a per-gamemode composite key. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Move the per-gamemode facts (slot layout, player count, grep tag, queue path) out of queue-slots.ts into a single tests/gamemodes.ts. Behavior is unchanged — still QUEUE_CONFIG-driven, every queue still served at `/` — so that the coming multi-gamemode migration only widens this seam (env selection -> per-path, distinct paths per gamemode) instead of touching every spec. queue-slots.ts stays as a thin re-export shim to keep specs untouched. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
Playwright test results
Details
|
This was referenced Aug 27, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
First PR of the multi-gamemode (5.0.0) stack — pure groundwork, no behavior change.
Why
The e2e suite scatters per-gamemode facts (slot layout, player count,
@6v6/@9v9grep tag, queue path) acrossqueue-slots.ts, the page objects, and the specs. Before the real multi-gamemode migration (later in the stack) converts the suite from "one gamemode per CI run viaQUEUE_CONFIG" to "navigate/6v6,/9v9… within one instance", it helps to gather those facts behind a single seam so that migration only has to widen the seam instead of touching every spec.What
tests/gamemodes.ts— one source of truth: per-gamemodeclasses,path,tag, pluscurrentGamemode(),queueSlots(),getPlayerCount().tests/queue-slots.tsbecomes a thin re-export shim so specs are untouched.QueuePage.goto()navigates viagamemodes[currentGamemode()].path(still/today).Behavior is identical: still
QUEUE_CONFIG-driven, every queue still at/, CI matrix and specs unchanged. Verified the seam emits the exact same slot list/count for both6v6(12) and9v9(18).Also lands the stack's design docs:
CONTEXT.md(glossary) anddocs/adr/0001-global-game-numbering-with-merge-remap.md.