Do gamers developers use to write unit and integration tests? How common is it among puzzle developers? And among developers of MMORPGs and FPSes?
(I have no background in game development neither am I cogitating about working with it - it is just a doubt that occurred to me. So, no need of trying to convince me to write them, even because I already like to write automated tests.)
In general, unit and integration testing of games isn't that common. This is mostly because the rendering aspect of games is usually closely tied to the rest of the game mechanics that it can be very hard to actually write unit tests that work.
That said, unit testing can happen in game development, and if the code is set up for it, it can be of great benefit. However, it can be much more common to write automated tests for games, usually in the form of an AI program that can effectively play the game at a higher speed than a normal player. There's some excellent stories of developers doing just that in this question about automated testing. This sort of automated testing is potentially better, since unit testing might not catch a bug in the rendering engine, but an automated test is more likely to expose such a problem.
In the end, though, this all depends on the studio. Some studios will some sort of automated testing, while others might just hire 20 high school kids over the summer to play their game for hours on end.
In my experience, it's not very common.
Mostly unit testing doesn't occur because most game developers come from a time and culture before things like that were widespread, and therefore it's hard to make the argument now that such methods are necessary. This has become even more true in recent years with the expectation that the user is able to patch his own software after release.
Partly it's because the dominant language in the game development industry is C++ and that makes unit testing a little more cumbersome than other languages. Unit testing frameworks exist but they are not as easy to use as similar systems in more modern languages that can use reflection and similar tricks to speed up the detection of test cases.
Also, it's because games don't generally lend themselves to unit testing - much of the logic depends on semi-deterministic sources (eg. graphics hardware, input timings, the frame rate), much of the output is hard to measure (eg. on-screen graphics, sound effects) and some is almost meaningless outside of the full game context making (eg. complex reactive AI, physics simulations). There are exceptions - many, if you work hard to make the code that way - but on the whole testing is more expensive in games than in most other types of software and so the cost/benefit ratio is more dubious.
As for integration testing, I've never heard of the term being explicitly used in game development but many developers do conduct automated tests of the whole system where possible. At a guess I'd say maybe 1 in 3 pro developers do this, as it's not always easy to set up, and because the benefits are reduced by the fact that pretty much every medium to large developer (or their publisher) has a QA department that will manually perform similar tests. QA are typically paid much less than developers so it may be considered economical to leave testing to them, rather than to invest extra code time on it. (Controversial.)
In general automating UI testing (even in regular programs) is harder than regular automation. So even though you can write unit tests for your games, testing the actual game is harder. Most companies use human testers that run the game time and again.
For example Here is an article explaining how they do it in a small Game Studio (2 devs). From what I read it seems like their validation is not very detailed (automation starts the game and logs any errors/asserts).
However some companies are very successful with semi automation (Such as Microsoft Test Studios). That is, Developers or SDETs build tools that make testing the game much easier. There have been Gamefest talks where they discuss how they tested Crackdown for example or Fable. For example, they still use testers that verify that every object is where it's supposed to be but they use a tool that takes a snapshot of that location so that all that the human does is visually verify it is there without having to play the game.
Here is a good talk on what kind of tools they build/use to test the games. It's called "Test Lead Gems: Getting Out in Front of the Increasing Complexity of Our Games"
I don't see how writing a game is different to any other piece of software as far as testing goes. Each component of the software, whether it be triggering a timed event, sending commands to an in-game character, or pressing menu buttons, should be tested for proper execution.
Testing whether the game is possible to complete is a different matter and doesn't fall under unit or integration testing so much.
I participated in a roundtable discussion about automated testing at GDC 2011. IIRC, there were about 60 people in the room. At one point the moderator took a survey of unit test coverage. There was one person who claimed greater than 90% code coverage. Everyone else laughed at the thought of ever reaching 1% coverage. If that group is a fair representation of the industry as a whole, I'd say automated testing generally doesn't happen much, if at all.
The other answers here give good reasons as to why. I just thought it would be useful to have a first-hand account.
I would wager that MMO and multiplayer server code, however, is a bit more often tested.
At the very least, automated regression tests have been common. I've seen these implemented as mass sanity-checks during server start-up, to e.g. make sure that a new "cloud" server was configured correctly before it begins accepting players; a fairly good regression suite built up over 3-4 years, in that case, ran in about 4 seconds, while bringing up a virtual host (from a blank OS image) took almost 10 minutes, so it was well worth the time. We ran the same tests on a "tinderbox" (continual build system) on our Subversion repository to check for some annoying, fairly common errors that liked to creep back in. In particular, the multi-server functionality had a nasty habit of trying to create duplicates of objects as they were passed around: the object instantiation, caching, and network-passing code was close to 100% covered; we kept thinking we'd thought of everything that could be tested, and then discover some “fun,” new edge case.
At several MMO's that I've worked on, we also would develop "stub clients" to perform initial unit-testing, and usually provided "operator" commands to do ad-hoc unit testing of new features. This let us execute server code before the client was ready to take advantage of it, and exercise "impossible" situations (e.g. teleporting a player inside of a wall) to ensure that the error recovery handlers would work well. Bringing a new feature online on the server might sometimes take many days less than the client support for it; conversely, we'd sometimes have to create a "dummy" server method for the client, returning fake-but-well-formed data, if they got ahead of us.
However, MMO development in general is subject to a lot more of these kinds of problems, which might reflect the environment. When I was working on embedded game systems, “testing” was practically unheard-of for anything except some reusable widget code (e.g. text editors).
Another reason why automated testing is not that common in Game Development that may be considered is that for most games there are plenty of Beta testing volunteers who preceive Game Beta participation as an "edge" when the game is released. Automated testing has of course grown out of quality requirements, but also out of budget restrictions. Therefore, since in gaming there are plenty of experienced testers who are prepared to test for free, perhaps this is another reason automated tests are not that widespread.
