3ed16c2aaf
Per your direction: tests must be able to debug UI/UX behaviors and
must be performant. Playwright's bundled Chromium falls to SwiftShader
on Linux which is fine for visual scenarios but tanks anything where
fps matters. New attach-mode lets us drive YOUR Chrome (hardware GPU)
without needing Playwright to spawn its own.
test/attach.py:
- One-shot health check that connects to localhost:9222 (Chrome
already running with --remote-debugging-port). Doesn't spawn,
doesn't close. Just confirms attach + reports the FPS HUD value.
- peek.py and run.py already attach via CDP, so they work as-is
once Chrome is started with the debug port.
test/README.md:
- New "Two modes" section up front: attach (your real Chrome,
hardware) vs launch (Playwright Chromium, software). Each has a
legitimate use; perf-sensitive work goes through attach.
- Workflow:
google-chrome --remote-debugging-port=9222 \\
--user-data-dir=/tmp/voxel-dev-chrome http://localhost:8080/
python3 attach.py # health check
python3 run.py scenarios/ui-menu-open-close.yaml
New UI scenarios that drive interactions via DOM events / wasm calls,
not pixel screenshots. Render-independent, fast on any backend:
ui-menu-open-close.yaml Click ≡ → assert menu-open class →
click resume → assert closed.
ui-hotbar.yaml pointerdown on slot 4 → assert .active
moved. Digit1 keypress → assert .active
back to slot 0.
ui-respawn.yaml teleport into void → wait → assert
is_alive()===false + body.dead class +
death screen visible. Click respawn-btn
→ assert hp===20, alive===true.
ui-settings-sliders.yaml Slider .value = N + dispatch 'input' →
assert displayed value updates → unwind
so the page isn't left frozen.
README updates list all scenarios. No code in the game changed —
this is pure test-harness additions.
30 lines
1.3 KiB
YAML
30 lines
1.3 KiB
YAML
name: ui-hotbar
|
|
description: |
|
|
Verify hotbar selection via both DOM click and keyboard. The wasm
|
|
`select_block(u8)` exposes the selected id to the game; we read it
|
|
back via the menu's persistent setting OR by inspecting which slot
|
|
has the .active class. This test does not depend on rendering — it
|
|
drives DOM and asserts CSS / state.
|
|
|
|
steps:
|
|
- wait_for: "window.voxel_game && document.querySelectorAll('#hotbar .slot').length >= 10"
|
|
|
|
# Click slot 4 (sand). Verify .active class moves.
|
|
- eval: |
|
|
const slots = document.querySelectorAll('#hotbar .slot');
|
|
slots[3].dispatchEvent(new PointerEvent('pointerdown', { bubbles: true }));
|
|
- wait: 150
|
|
- assert: "document.querySelectorAll('#hotbar .slot')[3].classList.contains('active')"
|
|
- assert: "!document.querySelectorAll('#hotbar .slot')[0].classList.contains('active')"
|
|
|
|
# Press keyboard Digit1 to switch to slot 0 (grass).
|
|
- key: Digit1
|
|
- wait: 150
|
|
- assert: "document.querySelectorAll('#hotbar .slot')[0].classList.contains('active')"
|
|
- assert: "!document.querySelectorAll('#hotbar .slot')[3].classList.contains('active')"
|
|
|
|
# Cycle wheel — bind a wheel event programmatically (skip — the
|
|
# real test is that mouse wheel cycles the hotbar; covered by
|
|
# the production app, hard to drive synthetically here).
|
|
|
|
- screenshot: hotbar-state.png
|