[pton_xd]

There are some game systems that lend themselves to unit testing, like say map generation to ensure that the expected landmarks are placed reasonably, or rooms are connected, or whatever. But most game interactions are just not easily "unit testable" since they happen across frames (eg over time). How would you unit test an enemy that spawns, moves towards the player, and attacks?

I'm sure you could conjure up any number of ways to do that, but they won't be trivial, and maintaining those tests while you iterate will only slow you down. And what's the point? Even if the unit-move-and-attack test passes, it's not going to tell you if it looks good, or if it's fun.

Ultimately you just have to play the game, constantly, to make sure the interactions are fun and working as you expect.

[coderenegade]

It would depend on how things are architected, but you could definitely test the components of your example in isolation (e.g. spawn test, get the movement vector in response to an enemy within a certain proximity, test that the state is set to attacking, whatever that looks like). I don't disagree that it's a hard problem. I run into similar issues with systems that use ML as some part of their core, and I've never come up with a satisfying solution. My strategy these days is to test the things that it makes sense to test, and accept that for some things (especially dynamic behavior of the system) you just have to use it and test it that way.

[chaps]

> How would you unit test an enemy that spawns, moves towards the player, and attacks?

You use a second enemy that spawns, moves towards the "enemy", and attacks.

[cherryteastain]

> How would you unit test an enemy that spawns, moves towards the player, and attacks?

You can easily write a 'simulation' version of your event loop and dependency inject that. Once time can be simulated, any deterministic interaction can be unit tested.

[mac-mc]

Others would quibble that those are integration tests, "UI" tests, or other higher-level tests, etc.

[9rx]

Which is all the same as what unit test was originally defined as.

You're right that "unit test" has taken on another, rather bizarre definition in the intervening years that doesn't reflect any kind of tests anyone actually writes in the real world, save where they are trying to write "unit tests" specifically to please the bizarre definition, but anyone concerned about definitional purity enough to quibble about it will use the original definition anyway...

[ryoshu]

A lot of games aren't deterministic within a scope of reasonable test coverage.

[greesil]

Set the same seed for the test?