Project Management

Use Fake to automate web testing on the Mac

Vincent Danen gives an overview of a new application for Mac OS X that automates interactions with a website so that developers can test code.

For anyone who does development, unit testing is a must. Writing tests for your code is essential to preventing regressions of functionality, and allows you to easily make sure that when adding a new feature, you're not breaking something else that had previously worked.

With web applications this is a little more difficult because of the interactive component to web testing -- to test an actual browser interface you typically need a person clicking around and testing things. Unit testing works great for backend code, but not so much for the frontend human interface.

Recently, a new application for OS X was made available: Fake. Fake is a tool that helps you automate interactions with a website. This can be for testing, for doing tedious and repetitive tasks, or for automating other web-based processing.

Fake is a lot like Automator in that it allows you to create workflows within a GUI. This is done by dragging actions sequentially into the workflow. There are different actions for various things: loading URLS, opening links in other tabs, clicking HTML elements, filling in HTML fields, and so forth. There are even actions that allow you to execute scripts (UNIX or AppleScript), send emails, and do if/else testing (do something if a certain condition is true, otherwise do something else).

It operates by having a WebKit-based browser window as the primary window pane, with the list of actions on the side. This allows you to inspect elements, so you can explicitly tell the workflow action what fields to operate on.

For instance, if you wanted to perform a login action, you would need four workflow items: "Load URL" to load the web page, "Set Value of HTML Element" for the username login field, another "Set Value of HTML Element" for the password field, and finally "Click HTML Element" which would click the login button.

Each of these items can be set by the element's name, id, CSS Selector, XPath, or by using JavaScript. So, for example, a bugzilla login field would have the HTML Element set by id (set to "Bugzilla_login_top") and a value of whatever email address used to log in. These elements can be found by right-clicking on a link or button and using the "Inspect Element" contextual menu item, which will then display the page's source in the bottom half of the browser window, highlighting the exact element. If a link or element does not have an id or name (such as a button or input field), you can also use the "with text" option to have Fake try to find the element displaying that text.

(Click to enlarge thumbnail.)

Surprisingly, Fake is quite easy to use. If you are at all familiar with Automator, Fake feels right at home. The demo version only allows you to add eight actions to a workflow, which makes it difficult to really get a feel for what is possible with Fake. It also does not allow you to save workflows you create. It would be nice if they allowed an unrestricted time-based trial in order to really allow someone to get into it and do some real testing. At $29.95USD, Fake isn't cheap, but if you do serious web development, it is a bargain. I really do wish the developers would make it easier to really give Fake a good trial, and this is really the only down-side to Fake that I've come across so far.

For any serious web developer, Fake would make a great addition to the arsenal of unique web development tools available on the Mac. Plenty of tools exist to save time in the development stages, but this is the only one I know of that can save considerable time in the testing stage of web application development.

About

Vincent Danen works on the Red Hat Security Response Team and lives in Canada. He has been writing about and developing on Linux for over 10 years and is a veteran Mac user.

2 comments
Vijay1002
Vijay1002

What are the other cost-effective automation tools for Mac/Safari.

Spitfire_Sysop
Spitfire_Sysop

It feels kinda like scratching your own back with one of those wooden back scratchies. I think that you would be in the same position of testing the program how you intended it to be used and not the way the users will actually use it. These things are rarely the same. It's great for proving your code does what you want but it doesn't prove that it won't do what you don't want.

Editor's Picks