Your first integration test#3
Conversation
Tayrtahn
left a comment
Tayrtahn
left a comment
There was a problem hiding this comment.
This is looking good! There's definitely a bunch of stuff I want to add eventually, but this is a great start for getting some documentation released!
| It can catch unintended behavior, bugs and even rare game-crashing errors when used properly! | ||
| This is achieved through **integration tests**, which basically run short simulations of the game and makes sure ingame values match what the test expects. | ||
|
|
||
| An example would be changing a Cargo order to cost less. |
There was a problem hiding this comment.
Mention the problem here and how it goes unnoticed, giving us reason to want a test
| If you have an integration test that compares order costs to sell values, you'll be able to automatically catch if this change would result in an infinite money loop! | ||
|
|
||
| Integration tests are ran on all pull requests submitted to the SS14 repository and all tests must pass for a PR to be mergeable. | ||
| You can also run tests locally in your IDE (useful if you fail a specific test when submitting a PR). |
There was a problem hiding this comment.
We should explain how - probably just linking to online guides for popular IDEs.
| For tests specifically it allows for client-servers to be reused for multiple tests and for tests to be run in parallel, instead of constantly starting and shutting down such systems. | ||
|
|
||
| It's unlikely you will access `PoolManager` yourself, but a key property that all integration tests make use of is the `TestPair` class. | ||
| `TestPair` gives access to the Client and Server instances and therefore the ability to set CVars, resolve manager/system dependencies and map management. |
There was a problem hiding this comment.
Possibly mention the threading behavior of tests here, with the test thread orchestrating the actions of the client and server threads.
|
Oh! It would be good to add a section about cleanup and recycling. By default, tests are assumed to have returned everything to (approximately) the initial state when they finish. A lot of this is done automatically though (anything parented to the test map is deleted when the map is deleted, |
Co-authored-by: Tayrtahn <tayrtahn@gmail.com>
| [Test] | ||
| public async Task HugTest() | ||
| { | ||
| var urist = await SpawnTarget("MobHuman"); |
There was a problem hiding this comment.
I don't want to make the example too complicated, but we probably should be using PR-worthy example code, and if someone submitted a PR with this, I'd tell them to move this to a private static readonly EntProtoId for validation.
| ### Clean-up & Recycling | ||
|
|
||
| To make integration tests run fast and efficiently, the testing system is set up to save time by reusing servers, clients and entity systems across multiple tests. | ||
| Much of this is handled automatically under the hood. `GameTest` deletes the test map and any entities in it when a test has finished, but there may be instances where you will have to clean up manually. |
There was a problem hiding this comment.
The test map stuff is handled in TestPair, so this works outside of GameTest too.
| }; | ||
| ``` | ||
|
|
||
| Luckily, our test is simple enough that letting `GameTest` handle the map deletion and clean-up automatically should be sufficient. |
There was a problem hiding this comment.
We're not using GameTest in our example, so
There was a problem hiding this comment.
Fair, I forgot InteractionTest doesn't inherit GameTest. Would would it work for this example?
There was a problem hiding this comment.
I.e. marking it Dirty
There was a problem hiding this comment.
No need to use Dirty, TestPair will clean up the test map.
2 participants
Review PR for Tayrtahn