Adam Christian

In preparation for the Windmill 2 client side re-architecting, and an article I am writing about simulating user sessions with JavaScript, I decided it was time to go through the Windmill JavaScript source and pull out the pieces necessary to drive a user session in JavaScript.

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.