It turns out that it’s easily broken into a few pieces:

• Events: Cross browser compatible event firing functionality
• ElementsLib: DOM element lookup functionality via many methods called ‘locators’
• Controller: The logic for firing the right events to simulate user actions such as ‘type’

In order to test all the functionality I wrote a small runner implementation, which was actually pretty fun and interested because of the need for waits and sleeps. As I didn’t want to have a continuous loop running, which has been the standard solution up to this point I decided to go about mine using a execution queue instead.

By ‘queue’ I mean that I’m using a JavaScript array with push and shift to keep track of what user actions need to be executed next. When a new action is pushed, if there is nothing in the stack it immediately executes, however if there are actions in the stack waiting those are then executed in order then it is executed. This works great, however there is one more level of complexity here involving sleeps and waits. If a sleep or wait is called a flag is set called ‘asleep’, that tells the executor to pop any new actions onto the stack instead of trying to execute them. When the sleep is done the asleep flag is turned off and all the actions in the stack that have been queued up are then executed in order.

Tests are very simple.

var test_run = function(){
wm.user('type',{'text':'testing', 'name':'q'});
wm.user('waits.sleep', {'ms':5000});
wm.user('type',{'text':'numbertwo', 'name':'q'});
wm.user('asserts.assertValue', {'name':'q', 'validator':'numbertwo'})
wm.user('waits.sleep', {'ms':3000});
wm.user('type',{'text':'finally', 'name':'q'});
wm.user('asserts.assertValue', {'name':'q', 'validator':'finally'})
}


This test can be executed against the Google Home page, and it simply types text in to the search box, sleeps a few times and asserts that the value typed in is actually in the form field when it should be. wm is the windmill code namespace, and user is the dispatch function that takes the method to executed and it’s parameters as an object.

Obviously as this was all taken out of the Windmill source all of the JUM functions are also available in wm.ctrl.asserts if you would like to mix them into your test.

So how would one use this?

There are actually a couple ways, one is to include the source in the page you want to test:

<script src="http://adamchristian.com/wmlite/wm-lite.js" type="text/javascript"></script>


or you can use the JavaScript Console to inject it into your page:

x = document.createElement('script')
x.src = "http://adamchristian.com/wmlite/wm-lite.js"
document.body.appendChild(x)


There is code that is executed when this file is included that figures out if the page has been loaded, if it has it calls in init function to enable the key shortcut listeners. If the page hasn’t been loaded, the window onload is pointed at the init so you are sure to have the shortcuts available to access the UI.

The short-cut is ALT-T. I was thinking ‘test’, meta-t and ctrl-t are almost always assigned by the browser but alt appears to work in all my test cases.

“Windmill-Lite UI Screenshot”

Why?

I don’t have a specific use case for this code/project but I know there are many uses out there for the functionality in the libraries, and for a low overhead cross browser litmus test tool it has some serious potential… also, it was fun.

Links

• GitHub: http://github.com/admc/windmill-lite/tree/master
• Compressed: http://adamchristian.com/wmlite/wm-lite.js

Additional Coolness

I’m sure there is something like this out there, but I got pretty annoyed trying to use various JavaScript compressor tools to make a single minified file, so I hacked one together in Python called ‘compressjsdir’. It requires jsmin.py, and you can find a zip of everything required here: http://adamchristian.com/code/compressjsdir.zip, or grab the source from github: http://github.com/admc/compressjsdir/tree/master

To run it you can simply do the following (after you put the compressjsdir directory in your path):

dhcp-10-10-9-230% cd directory_of_js_files
dhcp-10-10-9-230% compressjsdir.py
Reading and compressing...
Writing file...


There should now be a file called out.js, which is composed of all the js files in the directory minified and concatted together. This is all based on the JS compressor code Mikeal Rogers wrote for Windmill in our quest for performance.

I will be adding a couple easy features in the next few days, one of course is to take a parameter used to name the output file, and the other argument will be a comma delimited list for ordering of the files as they are minified and appear in the result (in case  you have dependent files).

More

If you are interested in more related or similar projects, you may want to check out FireUnit.

The first step is to get a couple machines that you want use as slaves and a machine to run Hudson, our setup looks like this:

Each of the machines with a different OS has Windmill installed. To make them slaves you simply bring up the Hudson web page on the machine, and run the launcher.. now it’s a slave — crazy easy right?

Now to setup test runs for the machines, in Hudson you click: “New Job” on the left hand side and do something like the following:

Tie this job to the slave you want it to run on (we can’t have IE runs happening on MacOSX):

Tell this job to run 10 and 30 minutes after the hour:

The build steps to actually run the tests, the first kills any straggling processes (more details below):

On the Mac for the Safari job, I want to make sure there aren’t any instances of Safari left hanging, or windmill processes sitting around so we do:
ps -ax | grep windmill | awk '{ print $1 }' | xargs kill | true
ps -ax | grep Safari | awk '{ print $1 }' | xargs kill | true


Then we want to grab the latest test code from svn and launch the windmill test:
svn up /Users/adam/Documents/main_bt/windmill/
python /usr/local/bin/windmill safari http://www.facebook.com test=/Users/adam/Documents/main_bt/windmill/fb email=username@slide.com password=pass report=true exit
rm /Users/adam/Library/Cookies/Cookies.plist


I am telling windmill to run a test against facebook.com, with the test hierarchy in the windmill/fb directory in Safari, with the provided email and password, then to report it’s results and exit.

The only thing different on our windows test runs is the way we kill the processes:
Example:
taskkill /F /T /IM windmill.exe
taskkill /F /T /IM firefox.exe


You might be asking how do I use those variables, check it out in my setup module:

1
2
3
4
5
6

def setup_module(module):
    client = WindmillTestClient(__name__)
    client.type(text=functest.registry['email'], id=u'email')
    client.type(text=functest.registry['password'], id=u'pass')
    client.click(id=u'doquicklogin')
    client.waits.forPageLoad(timeout=u'100000')

You can also read a great entry about adding reporting to your tests on Mikeal Rogers blog, here.

And that last line removing Cookies.plist makes sure that the next test run starts without any cookies set to cause problems.

Have Hudson keep you updated on Jabber:

Grab the generated XML output so you can view the test results in Hudson:

Do this for each of the test runs you would like to have, and boom — continuous integration:

This is obviously a simple scenario, and you can do way, way more customization.. but this should get you off the ground. Happy testing!