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.
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.
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.