Calling them Gremlins is actually a reference to the British Royal Air Force in WWII. The airmen would blame 'gremlins' for mechanical issues or even problems during flight.

http://en.wikipedia.org/wiki/Gremlin#Origins

Famous children's author Roald Dahl popularized them after he left the RAF to become a writer. If you get a chance, read a biography of Roald Dahl. He truely was the most interesting man in the world. (WWII Ace Fighter Pilot, British Secret Agent, invented a brain-heart valve, married an Academy Award winning actress, pioneered a stroke recovery program and sold over 100 million books.)

I remembered reading his books in my younger ages.

That's exactly why this method exists on Android. They have a similar testing tool called Monkey: http://developer.android.com/guide/developing/tools/monkey.h...

Doesn't it defeat the testing purpose if you perform a check to take a different code path when the testing tool runs?

The intended use for the Mac equivalent (described in the folklore.org story linked from another comment here) was to disable the quit command, so the test could be run for longer than it took the "monkey" to quit the application.

I imagine there are similar uses on Android.

You might avoid doing certain write-esque operations if you know you are in test mode. For example, you wouldn't want to charge a credit card or update someone's facebook status.

On the downside this might prevent some great dramatic literature from being created.

That makes sense. It didn't occur to me that someone might want to run a monkey test in a live environment, but I guess it is necessary sometimes.

I'd imagine there are occasional uses for it. You could use it to start the app with a particular state you wish to test with Monkey, while leaving it usable for human users.

It's meant to test some of the more extreme bounds of the system. Filling the event queue faster than the code can handle it, for example. Clicking in odd places at strange times and seeing unexpected behavior.

Monkey testing is going to expose things that you never anticipated in your test spec. It's a stress test.

Maybe. Sometimes no matter how hard you try test and production are significantly different. I wind up in a number of situations where any meaningful testing has to be done in production.

I'll assume that it's best to put in the check after you've found a bug. Perhaps something that the monkey triggers that isn't very high on your human-customer buglist.

I believe it's also called "fuzz testing"