The original Macintosh only had 128K bytes of RAM (that's one eighth of a megabyte), so dealing with memory management was usually the hardest part of writing both the system and applications. We allocated around 16K bytes for system use, and another 22K bytes for the 512 by 342 black and white screen, so applications were left with only 90K bytes or so. The bigger ones like MacWrite or MacPaint seemed to be bursting at the seams.

By the fall of 1983, MacWrite and MacPaint were pretty much feature complete but still needed a lot of testing, especially in low memory conditions. MacPaint needed to allocate three off-screen buffers, with each the size of the entire screen, so it was always skirting the edge of running out of memory, especially when you brought up a desk accesory, but the specific sequences that led to crashes were difficult to reproduce.

Steve Capps had been working on a "journaling" feature for the "Guided Tour" tutorial disc, where the Macintosh could demo itself by replaying back events that were recorded in a prior session. He realized that the so-called "journaling hooks" that were used to feed pre-recorded events to the system could also be the basis of a testing tool he called "The Monkey".

The Monkey was a small desk accessory that used the journaling hooks to feed random events to the current application, so the Macintosh seemed to be operated by an incredibly fast, somewhat angry monkey, banging away at the mouse and keyboard, generating clicks and drags at random positions with wild abandon. It had great potential as a testing tool, so Capps refined it to generate more semantically rich events, with a certain percentage of the events as menu commands, a certain percentage as window drags, etc.

The Monkey proved to be an excellent testing tool, and a great amusement, as well. Its manic activity was sort of hypnotic, and it was interesting to see what kind of MacPaint pictures the Monkey could draw, or if it would ever produce something intelligible in MacWrite. At first it could crash the system fairly easily, but soon we fixed the more obvious bugs. We thought it would be a good test for an application to see if it could run the Monkey all night, but usually it didn't run for more than 20 minutes, even if it didn't crash, because the Monkey would invariably select the quit command.

Bill Atkinson came up with the idea of defining a system flag called "MonkeyLives" (pronounced with a short "i" but often mispronounced with a long one), that indicated when the Monkey was running. The flag allowed MacPaint and other applications to test for the presence of the Monkey and disable the quit command while it was running, as well as other areas they wanted the Monkey to avoid. This allowed the Monkey to run all night, or even longer, driving the application through every possible situation.

We kept our system flags in an area of very low memory reserved for the system globals, starting at address 256 ($100 in hexadecimal), since the first 256 bytes were used as a scratch area. The very first slot in the system globals area, address 256, had just been freed up, so that's where we put the MonkeyLives boolean. The Monkey itself eventually faded into relative obscurity, as the 512K Macintosh eased the memory pressure, but its memory was kept alive by the curious name of the very first value defined in the system globals area.

For years and until I read this, I was sure that the Monkey application was somekind of a prank application, because I had it on a disk that was filled with pranks like that classic INIT (extension) that made your Mac burp when you ejected a disk. It's all clearer now :)

from klaymendk on April 13, 2005 15:06:03

Yeah, I had this app too, thinking more or less the same as Antoine. At any rate, my father (being then an employee of Apple in Copenhagen, Denmark) thougth this was a very bad application. I have to agree, it seems to be a poor way to do a complete code test. I am very surprised to read that this is an actual Apple concoction.

from benbot on April 20, 2005 15:38:27

I doubt they used it as a complete replacement for code testing. That would be silly. Seems to me it would be a useful tool, and tools are used in certain circumstances. Would you get rid of sledgehammers because they're no good pounding in a normal sized nail?

from Paul on January 20, 2006 04:44:56

When I started at Apple, I worked on a test tool called Virtual User. It had been developed in the late 80's. It used the same principle as the Monkey program but was structured and used as test tool.

from Steve White on February 02, 2007 01:05:34

For those looking for a copy of the Monkey DA, Google Groups has a copy archived here:
http://groups.google.com/group/comp.sys.mac/browse_thread/thread/739b8758ff0a00cf/8820dda00b710908?lnk=st&rnum=3#8820dda00b710908

from Ois&#195;&#173;n Mac Fheara&#195;&#173; on March 12, 2007 15:19:31

Jan:
I think, on the contrary, it's a great testing tool. Standard unit/integration/UAT testing are brilliant and necessary, but they don't really address the interactions between boundaries much - memory manager / GUI stuff / application layers and the like. This kind of frenzied random activity seems like a good tool for specifically testing those interactions. And of course, not a replacement for other forms of testing.
There was some hubbub about "mutation testing" recently, where the code is randomly mutated (eg: a condition is inverted, or constant assignments messed with/deleted) and if the tests still pass, then the mutation test registers a failure. This is another "interesting and probably useful" testing method that should coexist with more traditional ones. The more the merrier!