Integration test example

[Douile]

Here is an example of integration tests using my net-replay-test library (better name in progress :) ).

This aims to close #66.

I feature gated the integration tests so people using the library don't have to pull the test library in as an extra dependency.

I've made this a draft as I think there are a few things to discuss:

• Whether using a library that replays packets like this is the best way to do integration tests: if the game query protocol is updated a new packet capture would need to be made.
• Whether we want to store the test JSON files in this repo: a lot of these files could inflate the size of the repository
• Whether the library should be pulled into the gamedig organization

Probably some other things as well.

[CosminPerRam]

I think this is an elegant solution for mocking a game server.

Whether we want to store the test JSON files in this repo: a lot of these files could inflate the size of the repository

I do not think this is a problem if it's not increasing the crate's size (afaik we can ignore files in cargo if I'm not wrong).

Whether using a library that replays packets like this is the best way to do integration tests: if the game query protocol is updated a new packet capture would need to be made.

This is the only problem for this approach: "what if a game protocol updates something?" but it comes with the advantages of not requiring actual servers, which would be very expensive to maintain for that many games (ahem, maybe possible if we would get a sponsor?).

Whether the library should be pulled into the gamedig organization.

Could be possible, but I do plan that the stuf we are doing on the rust version of the library, to also do on the node side, so having a separate repository for a tool for rust and a separate repository for a tool for node would be quite bothersome, integrating them into the library's repository, sure, why not, its for testing anyways.

[Douile]

I do not think this is a problem if it's not increasing the crate's size (afaik we can ignore files in cargo if I'm not wrong).

If we don't include in crate though the integration tests would fail if someone runs the tests when this crate is a dependency (if they enable the integration test feature).

This is the only problem for this approach: "what if a game protocol updates something?" but it comes with the advantages of not requiring actual servers, which would be very expensive to maintain for that many games (ahem, maybe possible if we would get a sponsor?).

We wouldn't need to maintain per-se, the test runner could launch a new game server to run a test with something like linux game server manager (which uses gamedig btw) and then stop the server after test is done. That would still take a lot of CI time though: downloading TF2 server takes around 30 minutes. And linux gsm docker images don't include the server pre-downloaded (i assume for legal reasons). Maybe we could have integration tests run on time intervals like weekly through a sponsor..

but I do plan that the stuf we are doing on the rust version of the library, to also do on the node side

This test library used here also supports testing the node version, although only through using the command line node tool at the moment.

[CosminPerRam]

This test library used here also supports testing the node version, although only through using the command line node tool at the moment.

Just what I wanted to ask, as of right know I can't think of a better way to do integration tests, would you be interested in moving the ownership of the library to gamedig (while maybe maintaining it for a while)? It's totally alright if not, but I suggested this as I think it will be the core of future integration tests and I would want to maintain it if it would be the case that you wouldn't be interested in maintaining it anymore, if so I could just fork it, but wanted to ask (:

[Douile]

This test library used here also supports testing the node version, although only through using the command line node tool at the moment.

Just what I wanted to ask, as of right know I can't think of a better way to do integration tests, would you be interested in moving the ownership of the library to gamedig (while maybe maintaining it for a while)? It's totally alright if not, but I suggested this as I think it will be the core of future integration tests and I would want to maintain it if it would be the case that you wouldn't be interested in maintaining it anymore, if so I could just fork it, but wanted to ask (:

Yeah I would be happy to move to gamedig org, and also maintain it. Org is added insurance in-case I get hit by a bus or something. The library was designed to be used with gamedig and I don't intend to use it for anything else so might as well be there.

It will need a bit more work to get a release out for it so it's ready to add as a test-dependency.

[cainthebest]

Merged main into this PR, this does break some things as this was pre-monorepo. Test just needs to be added to lib cargo and test dir