-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
data verification / validation #840
Comments
refs #840 Co-authored-by: Scott Foster <[email protected]>
validate command implemented in 8fb9d3a checks against the following data points:
|
Doesn't make a ton of sense on second thought, since we want to be testing how the persistence of the game events reacts to changes as well as the simulation. Best to just define a more thorough stream of events |
encountered an issue where the simulated and actual accomplishment decks were out of sync since this data is not persisted and the replay just makes its own shuffled deck. for this purpose its being regarded as junk data and we just look at the cards that are visible to the player (purchased and purchasable) ref #840
30df3a0 increases coverage in the replay test. Its not too elegant, it mostly just extends the existing strategy of speccing out an event stream, replaying and making assertions against the simulation, but should reasonably cover potential breaking changes. |
tests
increase test coverage in
replay.test.ts
to ensure that in-game actions are persisted properly@sgfost has a good suggestion to take an existing game playthrough and convert it into a data fixture that can be loaded into the test database and then we make assertions against that canned game
CLI validation
create a general CLI validate game command that takes a game id or game ids and validates the game state for that game. This
validate
function could potentially be put into theGameReplayer
class in services/replay.ts and be used in by the test aboveThe text was updated successfully, but these errors were encountered: