My current employer is built around a couple of concepts: certain kinds of needs are better served on demand than by buying a tool, and certain kinds of software testing (in our case, application security testing) can be automated. There are other concepts that come into our business model, but those are kind of at the core of what we do.
Like so many other things in the world, our concepts aren’t new (though we do have some unique tricks that make them uniquely valuable). Automated testing, in particular, has a long lineage. I didn’t realize how long, however, until I came across a reference to MonkeyDA on Andy Hertzfeld’s Folklore.org, a collection of stories about the creation of the Macintosh.
MonkeyDA was a Desk Accessory, a tiny program that could be run without forcing another program to quit. (Desk accessories were a response to the lack of multitasking in the early Mac OS, and the many use cases of working with a modern graphical computer that essentially demanded having two programs open at once. They ran on top of the currently running program in a different memory space.) But it was a “special” DA. It simulated user interactions with the Mac, by feeding a random stream of events to the OS resulting in the cursor moving on the screen, text being typed, menu items being selected, etc. It was kind of designed to see if it could break the Mac OS or its applications by subjecting it to all sorts of abuse—just like a monkey banging away at the keyboard and mouse would. If the program crashed, it meant the Monkey had found a condition that a user might eventually find. The Monkey is no substitute for human testing based on test cases, but it’s an important complement.
The punch line, of course, is the size of the Monkey program. Written back in October 1983, its binhex is only 2791 characters long. That’s less than 3K of compressed code. That you could create that much mayhem with that small a program is a reminder that code has power, and that you never know what someone else’s code is going to do.