There is a perfect and apt answer: keep playing the game (prototype) you are developing!

Not only does it test your game under sort of realistic conditions; it also gives you constant feedback on whether the game is fun, interesting, engaging — something that's infeasible to test by code.

This exercises the happy path, but otherwise works surprisingly badly for testing. You already know what the game is supposed to be about, so you can't really tell how well the interface communicates things to someone who doesn't, and you more or less automatically play it the way you're "supposed to", so you rarely hit the sorts of buggy or game breaking corner cases testing is supposed to discover.

That's why you have playtesters.

That is not an answer, you are not describing anything close to TDD.

I think it's the closest thing to TDD you can have developing a game proper.

Development of a game engine is a different matter, and affords itself to classical TDD, to my mind. You can write formal tests ahead of time, because you can feasibly understand what you want to be implement before you implement that.

Try to TDD a shader pipeline workflow.

No code before a red unit test.