Setup integration tests verifying that match state is synced correctly

[randomPoison]

The way client/server communication is setup for mahjong matches has the client and server each maintaining their own (slightly different) copies of the match state. As the player performs actions on the client, the client updates its local state immediately and simulates forward from the last known server state. As the server applies player actions to the state it broadcasts the update events to the connected clients, at which point the client merges the update into its last known record of the server state and reconciles any differences with the expected state. This approach of only communicating state changes between the client and server is efficient in terms of bandwidth, but means that our logic for applying updates to state is completely lossless or we risk the client and server states desyncing.

We should setup integration tests that simulates the basic flow for a mahjong match and verifies that the client and server state remain in sync at the appropriate points.

Test Flow

Specifically, there are 3 different copies of the state that we need to check at various points:

• The server's state.
• The client's copy of the last known state of the server.
• The client's local state, which may reflect actions performed locally that have not yet been processed by the server.

The testing flow should be as follows:

1. The player performs an action based on the current state. This action is initially applied to the client's local state and then sent to the server.
2. The server applies the action. At this point the server state should match the client's local state.
3. The server broadcasts the state update to all clients.
4. The client applies the state update to its local copy of the server state. At this point all three states should be in sync.

That flow should repeat for all clients until the match is done.

Local vs Remote State

One minor wrinkle for setting this up is that the client and server have asymmetric state tracking: The server knows the full state of the match, but the clients only know their own tiles and the open tiles for the other players. This means we'll need a bit of extra logic to verify that the locally-visible state for each client matches the relevant portion of the server's state, since we can't compare them directly.