[ECO-4786] Document private API usage in tests

[lawrence-forooghian]

Resolves ECO-4786.

[VeskeR]

Great investigation of private API usage!

So it seems like we would still need to figure out what to do with stuff like:

• accessing private client options like webSocketConnectTimeout;
• accessing channel.channelOptions, rest.serverTimeOffset, realtime.connection.connectionManager.options properties;
• modifying values for suspendedChannel.state, connectionManager.lastActivity;
• private method calls realtime.connection.connectionManager.disconnectAllTransports();

as they are not something that proxy server solves for us.

And I have a couple of more concerete questions/thoughts on some points below.

[VeskeR]

not sure what this and channel.sync(); below does, might be tricky to replace in UTS

[lawrence-forooghian]

Didn't give it any thought whilst working on this document, but:

• waitSync — might be something we can replace with presence.get() with waitForSync set to true
• sync — yeah, don't know what that does; the end result is that it sends a SYNC protocol message (which I can't even see the spec mentioning as something the client should do, except for RTP19 which describes how a test should behave; I’m probably missing something though)

[VeskeR]

thanks! Will keep this open as it might be useful for others to see the discussion

[VeskeR]

can this API be replaced with proxy functionality? Like inject a presence message to add a member.

[lawrence-forooghian]

I can't answer this question with much certainty without spending some time reminding myself of how presence works. But the thing is that the feature that this is testing — automatic presence re-entry, as described by RTP17g — is specified in terms of a private API; that is, the spec point refers to the "internal PresenceMap".

[lawrence-forooghian]

So if you have a spec point that says "some action needs to be done for all members of this private data structure", it's fair enough for the test to insert something into that private data structure to check that the action is done for it.

[lawrence-forooghian]

The fact that some of the library behaviour is specified in terms of private API means that it's unlikely we'll be able to completely remove private API usage from the tests.

[lawrence-forooghian]

So it seems like we would still need to figure out what to do with stuff like (…)

Yeah, I haven't thought about those at all. If following my suggested approach in the protocol message interception RFC —

1. Reduce the test suite’s usage of private API as much as is practically possible;
2. For the remaining necessary usage of private API in the test suite, define a common testing private API to be implemented across all of our SDKs, which can then be exposed by our adapters and hence used by the test suite.

— we’d begin by seeing whether we can rewrite the test to not use the private API.