The latest articles on DEV Community by yulingg zhang (@yulingg_zhang_dfbce7a345a). https://dev.to/yulingg_zhang_dfbce7a345a https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4112509%2Ff1b8ba84-b1bf-428a-8f3d-fe385fd89606.png https://dev.to/yulingg_zhang_dfbce7a345a en yulingg zhang Sun, 06 Sep 2026 15:38:25 +0000 https://dev.to/yulingg_zhang_dfbce7a345a/testing-a-deterministic-browser-game-seeds-replay-and-invalid-state-12ob https://dev.to/yulingg_zhang_dfbce7a345a/testing-a-deterministic-browser-game-seeds-replay-and-invalid-state-12ob <p>A random game is easier to debug when the same inputs produce the same result. In HoopTrait, a browser basketball project, the Lab mode combines eight selected traits and generates a fictional career. The interesting engineering problem is keeping replay, sharing and validation consistent.</p> <p>This is a technical development note, not a claim that a game score predicts an athlete's real performance.</p> <h2> Store the decisions, not just the result </h2> <p>The Lab state records a seed, a dataset version and an ordered list of actions. An action is a pick or a reroll. Replaying those actions reconstructs the build.</p> <p>A seed alone is not a complete replay contract: changing the player pool or its order can change a seeded draw. A dataset version therefore matters alongside the random seed. For a future release, the same principle should apply to changes in the rules themselves.</p> <h2> Test invariants across many runs </h2> <p>The Lab test suite iterates through 1,000 seeds. For each seed it shuffles the order of the eight skills, uses the two allowed rerolls, and completes a build. It checks that:</p> <ul> <li>Eight distinct players were selected.</li> <li>All eight traits are present, and no player remains to be drawn after completion.</li> <li>The overall game score stays between 0 and 99 and matches the shared rating function.</li> <li>Packing and unpacking the share state returns the original state.</li> <li>Recomputing the fictional career returns the same output.</li> <li>The ten simulated seasons sum to the displayed career earnings.</li> </ul> <p>Those assertions catch different problems. A stable score does not prove that a shared link reproduces the same selections. A complete build does not prove that its season totals add up.</p> <h2> Reject impossible histories </h2> <p>A share payload is untrusted input, even in a client-side game. Negative or fractional seeds, duplicate skill picks, a third reroll, unknown action types, a mismatched dataset version and actions after completion are rejected.</p> <p>The tests also cover malformed encoded payloads and unexpected fields. Local state is useful for a casual game, but it is not an anti-cheat system. A competitive leaderboard would need a separate trust model.</p> <h2> Make daily challenges explicit </h2> <p>Daily challenges use a validated UTC date to derive the seed. The tests reject impossible dates and check that changing the date without the matching seed invalidates the state. This avoids treating a player's local midnight as a universal boundary.</p> <h2> What these tests do not establish </h2> <p>Determinism proves repeatability, not realism. The career is an entertainment simulation, not a forecast. Unit tests also do not replace mobile interaction testing, data-quality review or permission checks for third-party assets.</p> <p>Project reference: <a href="https://hooptrait.app/?utm_source=devto&amp;utm_medium=community&amp;utm_campaign=lab_testing_note" rel="noopener noreferrer">HoopTrait</a>.</p> <p>For developers working on small games: what would you version first when introducing a new scoring model—the replay format, the dataset, or both?</p> <p><em>Drafted with AI assistance and checked against the project's Lab test source.</em></p> debugging gamedev softwareengineering testing