Write down what survives each boundary
Create a small table for run restart, page reload, and a new browser session. Example: current score resets on restart; personal best survives reload; active level returns to level one after a new session. Name each value and the boundary it crosses. This makes it possible to spot accidental persistence, such as a previous run’s timer remaining visible after Restart, or accidental loss, such as a best score disappearing on reload.
Probe missing, malformed and old values
Try a first visit with no saved key, then a valid saved score, then an empty or malformed value if you can control the test environment. A robust game should choose a defined fallback rather than display NaN, lock the menu, or crash before play. If a score has a maximum or must be a number, test negative, unexpectedly large, and nonnumeric inputs at the data boundary. These are resilience checks, not assumptions that players can edit storage through the product.
Questions about testing game save state
What should a game save between sessions?
That depends on the intended experience. State explicitly whether settings, best scores, progress, and in-progress runs persist, then test each at reload and new-session boundaries.
Is localStorage guaranteed to be available?
No storage choice should be treated as an unconditional guarantee. Handle missing or unusable data gracefully and verify the game's fallback behavior in your supported environments.