It's been many years since I did gamedev but on top of the nice answer, there are some things I want to add and detail.
First already mentioned is that the output is just visual and auditory against tight "FPS-critical" constraints and computational/memory budgets. Ideas of correctness get blurry when the questions are more like, "Does it look good? Does it run smoothly without any stutters? Does it sound great?" while developers are tweaking and tuning and approximating while designer/dev collaborations lead to things looking and sounding slightly different with every rapid iteration.
Another one is that the testers can be awesome! I've never found a more dedicated group of testers in any other domain, since they want to test the software. They're having fun. They're addicted and sleeping next to the computer while exploring every nook and cranny of your game. It becomes pretty easy to discover even the obscurest glitches when people are actually entertained thoroughly testing every corner of the software while practically addicted to it. In my current industry the testers are a bit more difficult to work with since many of them are professionals tying their livelihood to the software, and so they rely on a handful of features to get their work done and aren't necessarily that interested in exhausting every nook and cranny all the time. Naturally when we can't rely as heavily on human testers, we need more automated testing.
Yet another is that the codebase for a game typically isn't maintained and modified and extended for years and years. It's not like the developers of Super Mario who originally developed it in 6502 assembly have had to maintain anything resembling that original code long after the game shipped. Doom 3 probably uses zero lines of code (or close) from Doom 1. If there's a continuing franchise, the newer games are more like "sequels" than "upgrades". Most games just ship and maybe release some patches, DLCs, and then the code is done. That's a huge contrast from my VFX industry where I've worked on maintaining code dating back to Amiga days which had been ported and maintained for decades. Games typically don't have 30-year old codebases let alone decade-old codebases still being maintained and aggressively changed today.
One of the reasons for this short-lived nature of game codebases is that they are so tied to the hardware. When combined with their cutting-edge nature and FPS-critical requirements, they often can't be developed in a way that abstracts hardware details, not even close. They're often written very specifically for the target generation of hardware, and it's usually not long before that PS3 becomes replaced by a PS4 which then becomes obsolete and replaced by a PS5, and so forth, and all very rapidly. The hardware capabilities play such a pivotal role in the game's design and development that it's generally not worth trying to maintain a lot of the same code written for PSX as for PS4, e.g. Most game franchises which last for generations still write their next-gen engines largely from ground-up for the newest hardware.
With a short-lived codebase comes limited maintenance time (i.e., a limited time in which the code has to be modified). With a limited time for the code to be changed that doesn't span years with the scope of the engine growing larger and larger with each upgrade, and combined with the fact that games are nowhere close to mission-critical, there's not such an absolutely critical need to apply the most exhaustive unit and integration testing. There's no benefit to doing that in ensuring the integrity of future changes if future changes aren't going to be made, and the unit testing and refactoring aspect of legacy codebases is naturally irrelevant if there's no "legacy" in the first place.
Another small one that isn't always relevant is that a game might only target a very narrow range of hardware without any desktop ports. In those cases a huge source of unpredictable glitches in these contexts, which is users running the software with radically different hardware and drivers, is eliminated.
That said, integration testing at the highest/coarsest-level tends to be more immediately useful. For example, many games might utilize a way to record how the game state is changing over time for "replays". Such replay features can ensure that the game is deterministic and also be used as a form of a testing tool on its own to replay back a game session recorded previously by someone else.
I've also encountered gamedevs working in small studios who did things like write bots for their game and had the bots play their game at max speed and ran that simulation, originally encountering an obscure crash after a day or two, then fixed it, then ran the simulation again, and repeated until there were no more show-stopping crashes even after running it for weeks on end. So there are interesting kinds of pragmatic approaches like that which I've seen from gamedevs to testing their software, but often in ways that resemble the coarsest level of integration testing and simulating things very closely to how the players actually interact with the game.
Finally these big AAA game engines are starting to resemble a whole different kind of beast: longer-lived, successfully abstracting the hardware a little better, with bigger codebases and longer maintenance spans while their level editors are starting to resemble full-blown development environments. I imagine those big engines would probably call for more thorough testing procedure, especially if the time their code is maintained expands considerably. Still a lot of game studios don't write huge AAA game engines: they either license them or develop a small proprietary engine which is considerably smaller in scope and isn't going to be maintained for years.
