As a kid, I loved playing the game Mouse Trap. Well, not really…in fact, I can’t remember the rules or gameplay all that well. I can only recall actually playing the game a couple of times. What I do recall was enjoying building the elaborate contraption that wound up being the mousetrap. Who didn’t love seeing if the ball would drop through the bathtub onto the seesaw so it could catapult the man into the empty swimming pool (or whatever the heck it was)?

It wasn’t until much later in life that I learned about Rube Goldberg and his wonderfully complex machines. Per his website, Goldberg “was a Pulitzer Prize-winning cartoonist best known for his zany invention cartoons.” These zany inventions have come to be known as Rube Goldberg Machines: incredibly complicated systems that perform simple tasks. See, as an example, the Self Operating Napkin. The contraption built during the Mouse Trap game can be considered a Rube Goldberg Machine.

In a drive to reach our testing panacea, it’s tempting to assemble a flow through multiple tools, products, systems, and files.

Take, for example, Selenium. Selenium is great at interacting with a browser and the DOM on web pages. What it’s not good at is, well, anything else. It does not interact with non-browser windows, the file system, or the machine/OS in general. Selenium is simply a browser interaction tool. Unfortunately, some of the constructs that get created to make a web user’s experience a pleasant one also make it difficult to automate. Take, for example, Flash (yes I know, Flash is going away). Flash is the bane of automation’s existence because most tools can’t interact with Flash components unless they are delivered appropriately. Spoiler alert: Flash components are not usually delivered appropriately. This leaves us struggling against that Pyrrhic endeavor of “complete automation”.

Suppose we decide to incorporate another tool into our framework to interact with Flash-based components. Sikuli is a great candidate; it has a good image recognition engine. We can feed portions of screenshots to Sikuli to drive that image recognition and subsequent component interaction (e.g. clicking).  We must, however, be aware of newly introduced the restrictions and limitations introduced by chaining tools together. For instance, Sikuli generally requires the screen to be unlocked and available in order to function. Also, the complexity of this Rube Goldberg machine may depend on which technology stack we are using. For instance, although Sikuli integrates easily with Java or Jython, we’ll have to be more creative when interfacing with other technology stacks.

Building Rube Goldberg Machines like this can easily become hard to maintain, thereby reducing or eliminating the value we intended. As in all situations, we must ensure we get value from our efforts, lest we inadvertently create our own version of Mouse Trap.

Like this? Catch me at an upcoming event!