Yup, in my domain (games) unit tests are common for functionality that is easily applicable to them (e.g. linear algebra libraries) then integration tests are more common for systems (e.g. testing collision systems integration with the game engine, do you get the right callbacks or whatever) but once you hit the game itself automated testing is not massively useful as it's usually painful to setup and maintain and only covers "does this case still work" with no information on how good the end product actually is.
IMO a lot of places have forgotten the value of manual testing in terms of not only finding bugs but actually understanding how the product is used. Games companies prize iteration speed in terms of how quickly you can test a change in situ because we as game makers need to verify our changes by playing the game. I'm making a multiplayer game right now so I need to make sure what I do works on the server and clients which usually necessitates three copies of the game running together. Then we playtest it with a larger group weekly and playtest with even larger groups less regularly.
My impression of a lot of modern development elsewhere is that as soon as automated tests are green the code gets punted into production which seems utterly bonkers.
IMO a lot of places have forgotten the value of manual testing in terms of not only finding bugs but actually understanding how the product is used. Games companies prize iteration speed in terms of how quickly you can test a change in situ because we as game makers need to verify our changes by playing the game. I'm making a multiplayer game right now so I need to make sure what I do works on the server and clients which usually necessitates three copies of the game running together. Then we playtest it with a larger group weekly and playtest with even larger groups less regularly.
My impression of a lot of modern development elsewhere is that as soon as automated tests are green the code gets punted into production which seems utterly bonkers.