[ensiferum]

Why would you say something like this?

With everything else being equal Unit tests are as useful for games and game engines as they are for any other type of software. If you care about your software being correct (or let's say less incorrect) you need to test it. And preferably you write automated tests. Games (and especially game engines) aren't really by default an exception to this.

(Of course you can just say that this game is not worth the effort of getting better quality so we don't care if it's a bug fest and that's fine).

[TinkersW]

I have never found Unit tests particularly useful outside of constrained situations where you have predictable input and output and a initial state that easily reached.

Getting a game(or engine) into a particular initial state so you can make the unit test even work would be a massive pain the ass.

Heavy assertions are more useful as they test actual running code, and they are executed every time the program is run. You can still write "unit test" like code using assertions, but having some code that only executes in the development build on startup to check your math library or whatnot.

Not defending Unreal, I don't particularly like that engine, but that has more to do with the codes age and bloat.

[ensiferum]

That doesn't sound right. Unit testing happens very close to the unit you want to test, i.e. class or function most of the time. Most of these should be designed with testing in mind so they're actually something you can write unit tests for. And there ought to be a whole bunch of classes/functions/components that can be tested this way, such as scripting code, networking code audio code etc.

It's not hard and definitely not impossible. Just requires a mind set towards quality and testing.