Build automated test suite for pi NES emulator extension
Session from pi-nes-sessions on Hugging Face by thomasmustier · MIT · condensed by Coders Talk
Set up automated tests for a pi terminal-based NES emulator extension to catch ROM loading failures, freezes, and rendering regressions across games like Zelda, Mario and Dragon Quest III.
- +0Prompt · +0Not sure how to automate testing for this NES emulator extension - want to check games load, don't freeze, and overlay renders correctly.
- +1mAgent did · +1mProposed a 4-layer test strategy (core/session/renderer/overlay) using public blargg/nestest ROMs, headless frame stepping, and golden framebuffer hashes for regression detection.
- +3mAgent did · +3mExplored the whole codebase (core, session, renderer, overlay, native Rust core), then scaffolded a tests/ layout using blargg/nestest ROMs and golden frame hashes as proposed.
- Break · 30m away, not counted
- +6mIntervention · +6mSwitched to Claude and asked it to sanity-check whether the golden-hash/blargg-ROM approach actually tests what matters (games loading, not freezing, overlay rendering).Why: I wanted a second opinion before building tests on an approach that felt academic rather than tied to my actual goals.
- +7mAgent did · +7mCritiqued the original plan: blargg/nestest ROMs test CPU accuracy not real games, golden frame hashes are brittle against timing changes, and a fake TUI wouldn't test actual rendering.
- Break · 48m away, not counted
- +7mAgent did · +7mRewrote the plan around real user ROMs already on disk: added unit tests for paths/roms/saves/config/input-map, a core-smoke test loading actual ROMs and stepping frames, and a regression test batch-running all ROMs, wiring it into package.json and getting the suite passing.
- +16mPrompt · +16mAdd scripted key sequences per game to catch freezes properly - e.g. for Dragon Quest III wait 3s, hit start, wait 3s and check the screen loaded; for Mario, load, wait, hit start, then move to see if the sprite appears.
- +17mAgent did · +17mBuilt game-scripts.ts with per-game input sequences, rewired regression.test.ts to run them, fixed a missing npm script, then wrote a debug-game.ts visual inspector which revealed background renders fine but sprites (Mario, Link, Samus) are missing across multiple games while Dragon Quest III's text-based screen animates correctly.
- +20mOutcome · +20mTest suite finished with unit tests for paths/roms/saves/config/input-map, a core-smoke test, and scripted regression tests across 4 ROMs, correctly catching a real sprite-rendering regression (missing sprites in Mario, Zelda, Metroid) via a new debug tool.
Next time I'd start by telling the agent explicitly which ROMs I actually care about and that I want tests tied to real gameplay symptoms (freezes, missing sprites) rather than emulator-accuracy test suites like blargg/nestest. Switching agents to get a second opinion on the original golden-hash/blargg plan is what actually saved the session - it correctly flagged that the first approach wouldn't have caught the real bug. The scripted key-sequence idea I gave partway through ended up being the thing that surfaced the actual sprite rendering regression.