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