Consider exporting `ApolloLink` testing utils

[trevor-scheer]

Hello! I'm writing a custom link and would appreciate a "blessed" way to go about testing them. I noticed some handy internal utils, notably ObservableStream that would be nice to have (and then I can just model our own tests after yours).

Is that something you'd be open to exposing publicly?

[jerelmiller]

Hey @trevor-scheer!

Our only hesitation with exposing ObservableStream right now is that its tied to jest and its methods for equality testing (I'd hate vitest users to have to install jest just to use it). We'd need to figure out how to provide similar functionality across the board (which I definitely think is possible). I do agree though it is super useful and would love to add it as a test utility at some point!

Are you opposed to copying the utility into your codebase for now? I did this recently for apollo-angular (which uses vitest; reference to changes).

"blessed" way to go about testing them

As for a "blessed" way, we typically use the ApolloLink.execute function to get the returned Observable, then assert on the values emitted by that observable to ensure they match what should be emitted. No special magic here.

If you're on v4, be aware that we added a third argument to execute which requires you to pass a client instance. That client instance doesn't have to be anything special, its there so that the client is accessible by the link chain (e.g. operation.client).

I'd also recommend copying these utilities over which lets you call execute without the third argument: https://github.com/apollographql/apollo-client/blob/37555cee9e4e7d584a61fd9c5833842d562feaa4/src/testing/internal/link.ts

Those are something I'd also like to move over as a stable test utility. At the very least, we aren't doing a great job of documenting this!

Sorry I don't have a better story for you here yet!

[trevor-scheer]

Thanks for the quick reply @jerelmiller! That makes a lot of sense, I didn't spend too long thinking about it but it sounds like you already have a bit 🙂 we're eventually jest -> vitest so that's especially relevant!

I didn't get to look to closely but there's a TS error in ObservableStream on version-3.x that wasn't an obvious fix to me - maybe it'll be more clear to you. Let me know what you see there, I can get a repro if you don't see it. Otherwise I'm happy to copy it in indefinitely!