Decide approach to testing

[lawrence-forooghian]

I've deferred this from the initial setup of the library. A few options that I considered:

• make ably-cocoa expose an AblyPluginTesting library that provides a stable API for accessing the private API of ably-cocoa needed for testing
  • after Add module map for SPM ably-cocoa#2056 this could actually now be written in Swift
  • an earlier attempt at this, which I decided to drop, is at https://github.com/ably/ably-cocoa/tree/example-of-AblyPluginTesting
• directly import Ably.Private into the LiveObjects test suite — this is possible after Add module map for SPM ably-cocoa#2056, but obviously it's a non-stable API
• make ably-cocoa expose its existing test helpers via a library — I think this is a non-starter because lots of those helpers depend on Nimble and I think some are not async-friendly (i.e. blocking)

Need to decide whether it matters whether the plugin test suite has access to a stable testing API. We're in control of which version of ably-cocoa gets used for testing the plugin in CI, but we need to be sure that our plugin test suite won't get built as part of any user's build process (because then the user will be locked into a specific version of ably-cocoa, i.e. the one for which our non-stable API usage compiles, and we don't want that). I don't think that SPM will ever try building our test suite in a user's app but need to confirm.

Might start off with just using import Ably.Private directly and see how that goes. Don't yet have a great idea of how much private API usage we're even going to need (from looking at the ably-js LiveObjects tests, not loads).

┆Issue is synchronized with this Jira Task by Unito

[lawrence-forooghian]

make ably-cocoa expose an AblyPluginTesting library that provides a stable API for accessing the private API of ably-cocoa needed for testing

This one is a bit of a non-starter because Xcode would try and link it to users' apps, same problem as that which necessitated #69