Bug Fixes:

• Major fixes and updates for the Windmill Unit Tests
• IE fixes for: Drag and Drop, Click, UI usability, Non Compress deps broken
• JS Test Framework bug fixes, JUM assertions, unit tests,
• Improved XPath Generation and bug fixes

Feature

• Full support for launching and killing Google Chrome on Windows (requires Python 2.6)

We really appreciate all the bug reports and emails from you all, thanks for your patience as we try to squash all the bugs.

An additional encouraging note is that we got some great PR this week, which can be found here: Windmill Article in the SDTimes.

Happy testing.

The IDE has been growing organically since 0.1 and there was a lot of functionality hacked into it that wasn’t in the original game plan, so I did what I could to improve the beauty of the CSS/Layout as well as the whole mess of code behind it.

Launching
If you have used our latest release, or are running trunk you know that we have significantly improved the load times for the Windmill IDE. By compressing the JavaScript when the service is instantiated we can simply hand the IDE window one file that contains the vast majority of the required code.

The reason that this makes such a huge performance difference is because we are loading the source via the local windmill proxy and the data size size had very little impact, the overhead was in the browser two connection limit. When you have to pull down ~30 files two at a time it takes its toll and made the IDE feel very sluggish and more like a web page loading than an IDE.

In the process of figuring out exactly what was slowing down the launch time we added some more informative messages and output so you don’t sit there staring at a twirling circle graphic wondering if anything is happening. And to make the experience even more fun, I couldn’t help but implement a progress bar.

General Layout
I removed the toolbar at the bottom of the screen, which I felt it was an irritation for test editing (especially with the drag and droppable actions). It is now in a drop down menu at the top right of the screen, with the rest of the UI access to IDE functions.

Settings and Firebug Lite Improvements
The settings dialog has continued to improve by implementing more useful defaults, adding new options, removing deprecated options and simply making it just look better. Thanks jQuery UI!

Firebug Lite has been a very popular feature since we first announced it, which has led to a handful of bug fixes over the last month. The most major of these was that the initial Windmill implementation of Firebug Lite required you to have Internet access as it was using resources that were hosted elsewhere.

These have since been copied to our source tree and are made available by the Windmill server so you can happily introspect your Web Apps JavaScript while writing tests on your Intranet.

Output and Performance
Instead of writing all the raw windmill output to the output and performance tabs there is now an array called windmill.errorArr, where all terrible errors and warnings about technical details are pushed in the case you are interested to see all that data. However, it’s more likely that you aren’t and scrolling through all that output data becomes tedious.

This is why we have implemented output in blocks with the background color representing pass/failure with green/red (white for performance). These blocks are expandable, clicking them will reveal all output (or performance information) we know about the action that was executed. This should give you a faster general overview of your results and allow you to quickly see the details you care about.

Other Worthwhile Mentions
We moved our XPath implementation from Ajax-Slt to JS-XPath, which has proven to be more accurate when it comes to resolving XPath generated in Firefox (or using Firebug) against non XPath native browsers such as IE.

Many bugs and improvements have been made to the DOM Explorer, which should now feel a lot more like the Firebug DOM inspector, but should work in any browser.

We have also put a lot of effort into improving the communication between the JavaScript Controller and the Python Service so that when a test fails you get as much detailed information in the service as you do in the IDE.

Timing and MozMill
The timing has lined up nicely as we are working on both a 1.0 release for Windmill and MozMill. MozMill is geared towards automated testing of all applications on the Mozilla Platform and functions in the trusted space providing lots of very useful flexibility.

You can currently try out MozMill 1.0rc1 as a Firefox Add-on, and keep your eyes pealed as some exciting new MozMill feature work is around the corner.

Participate
We are always trying to make life easier for the test writer, so please log your bugs and feel free to come chat with us in #windmill on FreeNode.

The IRC channel is a great place to come chat with us if you are having any issues or questions. Again if you are new to Windmill its #windmill on FreeNode.

It’s a very exciting time for the project, stay tuned.

The windmill developers will be online in #windmill on irc.freenode.org from 10am to 5pm PST.

Even if you haven’t tried to install windmill before, come and give us feedback through the entire process and we’ll be there to help if you run in to any problems.

Hope to see you there.

-Mikeal

It’s usually a good idea to document cool features you write and tell people about them. I totally forgot about this one, which I wrote during DjangoCon a few months back.

A few years ago I wrote a patch for live server support in Django. The patch fell out of sync with trunk and was picked up a year or so later and substantially improved. But the patch didn’t end up making it in for 1.0 . Luckily the code is simple enough that I was able to use it windmill and add live server support to any Django 1.0 install by dynamically overriding and changing the classes that we need to start and stop a live test server for you django project.

After it’s all said and done this makes it dirt simple to bootstrap windmill tests from your Django unittests, all you need to do is define a single test class along side your other django unittests pointing to the directory of windmill tests you want to run and which browser you want to run them in and windmill’s django support will automatically start a live django server and run your windmill tests against it.

from os import path
from windmill.authoring import djangotest 
 
class WindmillTests(djangotest.WindmillDjangoUnitTest):
    test_dir = path.join(path.dirname(path.abspath(__file__)), 'windmilltests')
    browser = 'firefox'

This is also all written up on a wiki page along with some of the caveats.

Seriously Faster

On Wednesday Adam messaged me and said that the windmill startup time was too slow. He was right, we’ve know about this for a while but hadn’t put a lot of serious thought in to how we could reduce it.
The issue here was was that we have about 50 JavaScript files that need to get loaded for windmill to start.

Enter windmill-compressor, a new url namespace we added that concats all the js windmill needs in to one file and minifies it. We do this dynamically when windmill starts up, because adding a “build” step would just be too….. Java.

That reduced the startup time from 5-10 seconds to around 2 seconds. But that wasn’t good enough. We saw that most of that startup time was blocking waiting for the compressor to finish, so I threaded it when we start the windmill service and it does the compression while we wait for the browser to start up.

In all, windmill startup times are about 10x faster than 0.9!

Adam also decided to make our page load wait code a bit more aggressive which made not only startup times faster but all of our tests!

Native JavaScript Test Framework

We tied up the loose ends on the JavaScript testing framework and it can now shutdown all of windmill in it’s own teardown, hello continuous integration for native JavaScript tests

This was the last thing holding us back from promoting this along side the Python test authoring library.

We Love Firebug

In 0.9 we introduced Firebug Lite integration for windmill on all browsers. But when you’re using Firefox you probably still want to use the full Firebug extension, which is easy enough to integrate since we use mozrunner for Firefox launching.

Windmill now has a “firebug” command line argument that installs the full Firebug
extension when launching Firefox.

New Features, since 0.8.0

• Command line option for changing service port
• Django Support
• Forwarding Conditionals
• Addition of firebug lite support in IDE and Testing Application
• Fully functional wxWindmill contrib application
• Enhanced ’smart’ recorder
• Auto element scroll into view to more closely simulate users
• Improved IDE user interface
• Improved frame recursive element look ups for IE

In addition to all the bug fixes, which you can see for yourself in trac.

We are really excited to see the exponential growth and exposure the project has been getting over the past couple weeks, thanks everyone!

Windmill Team

For some time now we’ve always had a shell in Windmill for debugging but it was never as nice as the Firebug shell and maintaining that code was kind of a pain. In the recent 0.8.2 release of Windmill we dropped our old shell code and fully integrated Firebug Lite so that whenever you need to debug a test in any browser you can open Firebug Lite in the target application by clicking a single link in the Windmill IDE.

I can’t even begin to explain how much easier this is going to make writing and debugging tests in Windmill.

I’ve attended a lot of conferences; big conferences, small conferences, very targetted conferences and very broad conferences. I think DjangoCon may have been the best conference I’ve ever been to.

Over the years what I’ve learned to truly value about a conference is; meeting with people in the community, learning and understanding things I care about that would be harder to learn from reading than listening to a speaker, and just generally having a good time. DjangoCon was fantastic on all fronts. Being so targeted (people who use Django) there weren’t many talks that I didn’t care about and the people speaking were in all cases the best person to be speaking about a particular topic. The Django community is my favorite open source community, beating out the larger Python community by a small margin. Everyone is nice, helpful, and rarely suffer from even a marginal amount of smugness. Add food, decent wifi, and Cal’s talk “Why I hate Django” and you definitely cover the “having a good time” bit.

AppEngine

I messed with AppEngine for a couple weeks when it was first released. There were some serious rough edges that I decided I couldn’t deal with and I really didn’t completely get my head around the datastore.

Seeing Guido’s talk I noticed that those rough edges have been smoothed out and the development environment seems nicer, not to mention the documentation seems to have significantly improved. I’ve also been doing a lot of CouchDB work lately so I’ve internalized the “Document Store” concept and once I saw the Expando class provided by AppEngine I felt like I was now in a place where I can really understand Google’s datastore. It’s also not documented very well but Google’s datastore supports some geo data, which has always been a concern of mine putting too many eggs in the CouchDB basket right now. Add the fact that I absolutely hate managing infrastructure and I made a quick decision to invest once again in AppEngine or an upcoming project.

Why I Hate Django

I don’t think anyone will disagree that the highlight of Day One was Cal Henderson talk “Why I Hate Django”, he was absolutely hilarious. The video will be up eventually and I highly suggest everyone watch because it’s just too damn entertaining. I pulled a series of CC pictures from flickr in the meantime that illustrate the humor of the talk.

Live Testing

Something like two years ago I wrote a patch to add live server support to the Django Test Framework (based on unittest). That patch fell out of sync with trunk and on the floor at some point. Eventually an intern at Disqus came along and got it working again and made some really nice improvements.

Although the patch didn’t make it in to Django 1.0 I’m told it should land soon and will be in 3.1, but Disqus has been running with it all summer, using it for some Selenium tests. Well I couldn’t stand idle while Selenium test were running with Django and Windmill tests weren’t so I put my head down for about an hour during one of the talks and committed Django support to Windmill trunk. I ported the current patch for live server support in Django’s Trac so that it dynamically adds what is needed to Django and you can use this with Django 1.0 unmodified, and created a TestCase class that will launch your Windmill tests from within the normal Django python mange.py test runner. I wrote up a bit more about this in a post to the windmill-dev list.