Skip to content
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

Open
alee opened this issue Jan 4, 2023 · 3 comments
Open

data verification / validation #840

alee opened this issue Jan 4, 2023 · 3 comments

Comments

@alee
Copy link
Member

alee commented Jan 4, 2023

tests

increase test coverage in replay.test.ts to ensure that in-game actions are persisted properly

  1. include full coverage for in-game actions + activities: investment, trade, accomplishment purchase, discard, events
  2. use the persisted RoundSummary TakenStateSnapshot game events to sanity check that everything recorded is at it should be

@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 the GameReplayer class in services/replay.ts and be used in by the test above

alee added a commit that referenced this issue Jan 4, 2023
@sgfost
Copy link
Contributor

sgfost commented Jan 5, 2023

validate command implemented in 8fb9d3a

checks against the following data points:

  • system health
  • round number
  • logs length
  • messages length
  • mars events length
  • mars events processed
  • players:
    • role
    • is ready
    • time blocks
    • points
    • resource inventory

@sgfost sgfost mentioned this issue Jan 6, 2023
6 tasks
@sgfost
Copy link
Contributor

sgfost commented Jan 11, 2023

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

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

sgfost added a commit that referenced this issue Jan 11, 2023
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
@sgfost
Copy link
Contributor

sgfost commented Jan 11, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants