I know how a unit test works
you have an expected output and compare it to the result of actually running the code
but how do you do this for a videogame? do you have to implement a virtual player?
@efi i guess yea ? its what i'd do, or, if you have an action oriented game (ie, racing game, or tower defense, or turn based, etc), then a replay system ?
@SRAZKVT damn, ok... how the fuuuuck do I implement this in godot without going insane?
@efi unit tests are supposed to test subsystems or specific functions

So if you have, for example, a test for the AI you just feed data to the function that evaluates the AI and see what that function returns

It's all internal calls and made up data
@gwenthefops guess I just don't know what to test for?

@efi @gwenthefops I think the first thing to do in this case is to break up the code.

Say - if you have a video game you might have some code to handle a player, some code to handle the controls, some code to handle the environment, and some code to handle the enemies. There might be layers of abstraction too, e.g. there might be a UI layer and a "data store" layer.

Put those sections into separate modules, figure out what data goes in and what data you want to come out for each module, then test against that. Behold, those are unit tests.

You can also test the video game as a whole, those would be integration/acceptance tests. I'm not sure how you approach those in the context of video games.

@efi The thing is - you have layers of tests

Unit tests focus on testing often just individual functions

Component tests take a connected system of units - like the AI or rendering subsystem

Integration tests make sure components interact correctly - often testing completely assembled final product

Acceptance testing then takes the entire product, hands it to users and watches if it performs as intended with the target audience in the loop