e2e: a Game played to checkmate across two browsers #193
Labels
No labels
bug
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
spec
wayfinder:grilling
wayfinder:map
wayfinder:prototype
wayfinder:research
wayfinder:task
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Blocks
Depends on
#197 e2e: a Spectator watches a Room with both Seats taken
amaurycoudr/chess-project
#192 e2e: harness — create a Room and join it from a second browser
amaurycoudr/chess-project
Reference
amaurycoudr/chess-project#193
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Parent
#191
What to build
Two Players play a Game to checkmate in the same Room, each in their own browser, and both are told who won.
This establishes the two things every later multi-Player ticket needs: the helper that plays a Move by selecting a square and clicking its target, and the strategy for waiting until an SSE-driven update has actually landed in the other Player's browser. Both belong to the suite, not to any one test.
The Game is the four-Move mate. After each Move, both Players' boards are asserted to agree — a one-sided assertion would pass against a broken fan-out, so every shared behaviour is checked in both contexts.
Position assertion is targeted, never exhaustive: the squares the behaviour concerns, the status line, and the move list in readable notation. Nothing in the DOM exposes a machine-readable position and none is added. Checkmate itself needs no position read — the status line names the winner and the mated King's square carries its check attribute.
Acceptance criteria
mentioned in issue #197
mentioned in issue #192
marked this issue as related to #192
marked this issue as related to #197
mentioned in commit
ac398ab1c6