Make Party.Room constructor public about partykit HOT 2 OPEN

I have a proof of concept functional at kettanaito/tug-o-war@00bdfa6! It reuses my GameServer PartyServer instance in a test to rely on the same behaviors I do in production. I believe this is the way to go regarding testing. Also touches on what we've discussed over our call, @threepointone, regarding how to emulate behaviors in tests.

If we can provide a better experience around the Room and Storage APIs that'd be incredible. Currently, I mock the Room object and it's not nice 😬:

https://github.com/kettanaito/tug-o-war/blob/00bdfa6a9ebb05ef8b2dc521d4d3adec734fb82b/app/components/tug-o-war.test.tsx#L11-L32

Now, I agree that a mock Room instance won't be a 1-1 replica of the production room. I think a certain degree of deviation is always acceptable in mocks. Providing the minimum, which is the storage, broadcast can cover most of the test cases (and the Room class can manage connections, getConnection(), getConnections(, etc. internally; I get a feeling that's what it does anyway now). The important bit is that an interceptor can forward client events (and server events from the actual PartyServer) to the tested code.

from partykit.

Updates

Okay, after I've given this some more thought, I have concluded that reusing the actual PartyKit server for testing may not be the best idea. If you've constructed you server to support such a use case, I suppose you can do as you wish, but from the general testing practices perspective, I believe that's not a good way to set up a test.

My main motivation to rely on the actual WebSocket server was to reuse the existing behaviors of the server. Example: I send a pull event 10 times from the client and on the 10th time the server sends a finish event. This sounds like a logic crucial to have in a test. But in reality, it's not. It doesn't belong in the test.

That kind of logic doesn't belong in the test because it's not something the client knows or controls. The fact that the 10th pull must result in finish is server's logic, not the client's. Thus, to efficiently test the client in this scenario, what you should do is this:

1. Test that doing an action results in the pull event being sent.
2. Test that once the server sends a finish event, your client transitions into the correct state.

In the end, those are precisely the logic that the client defines and controls, and thus, also only logic that must be tested.

Now, you'd still test the actual 10 pulls -> complete in an end-to-end test with the actual/test WebSocket server running. My comments relate purely to integration-level testing.

With this conclusion, I don't think it's strictly necessary for PartyKit to expose primitives like Room for testing. I have achieved a decent integration test coverage without those primitives and without relying on PartyKit at all. Take a look at the example test suite here:

https://github.com/kettanaito/tug-o-war/blob/00872b6df7c1c20bf3676d579e209a13ada0210c/app/components/tug-o-war.test.tsx#L16-L18

from partykit.