Remove redundant unit-tests

[kristjanvalur]

The unit tests contain the same tests, for internal functionality, repeated for different integrations.
At least, this is the case for tests of protocols such as graphql-transport-ws. For aiohttp, asgi and fastapi, the same internal details are tested over again, only within the scope of different integration. There is no added benefit of having the same protocol test repeated three times (for synchronous and asynchronous client, plus two server integrations), not when the test is really not testing the integration at all but internal protocol logic.

Could we pick an integration to use to test the internals of graphql-transport-ws, (and maybe graphql-ws), to all of the functional testings using that integration, then for each integration we can test only those features which are peculiar to that integration?

[patrick91]

@kristjanvalur could we do something like we did for the http tests? one test for all the integrations?

I understand that one test might be enough for the internals, but I prefer to make sure all integrations are fully tested, even if there's repetition in what is being tested :)

Here's an example of http test we have: https://github.com/strawberry-graphql/strawberry/blob/main/tests/http/test_query.py#L9-L17

the http client is parametrize per integration 😊

[kristjanvalur]

It is tricky, because we have two synchronous integration and one async. We could at least parametrize the synchronous ones. There is also a lot of constantly repeated boilerplate which could be moved to fixtures. If that's the way you want to go about it, I could try to come up with a PR. Two sets of tests is less work than three :)

[kristjanvalur]

I've started working on this and it looks doable. I'll re-use the clients already created and extend the ABC with a ws_connect method.

There is altogether too much typing in there for my liking (testing is traditionally just mock everything and make it quack) but I'm learning to ABC as I go. I've been in this Python business since 2.2 :)

[kristjanvalur]

See PR #2635