Adam Christian

Over the last year, I have known that the day would come when I could no longer avoid moving from SVN (my comfort zone) to this new beast called GIT that everyone is so excited about. My first hour, which was installing it on my Mac and pulling down a repo to play with was very pleasant. My ssh keys and ~/.ssh/config was already setup the way I wanted and everything just worked.

The pain began when I started in on moving our build slaves over to GIT. Of course two of the three are running Windows because we have to run the Windmill tests against IE. In an attempt to keep things simple, I wanted to avoid installing cygwin on the machines, so I tried msysGIT. Oh WAIT I have to get ssh to work before I can actually use GIT to pull down the repo. 

After trying and failing with openSSH, I finally realized that the Windows puTTY Package was the best way to go about this. There was much frustration involved with this process because it requires that you take the ssh key you generated on your mac (and had added on the server) and convert it to a puTTY ppk. Fortunately this turns out not to be that panful using puTTYgen. The next piece to the puzzle was to get pageant to load this key automatically when the machine boots. I went through some rigamarole trying to create a shortcut in the “Startup” items and appending a string to it’s path to get it to load the correct key. This didn’t work, I’m sure it was a combination of Windows being terribly un user friendly and my brain expecting things to “Just Work TM”. Finally I just created a short cut for the actual key and stuck it in the “Startup” folder, and it works! (You still have to enter your pass phrase on boot) but its better than the alternatives. I actually found a post on a puTTY forum where someone was asking to automate this piece too and the response was basically, “No, never, die. Doing that defeats the purpose of SSH”. 

One step that I forgot to mention is that to get GIT to use the right SSH key you have to set the environment variable: GIT_SSH=path/to/putty/plink.exe

Next I went and started my git clone, which kicked off perfectly. That wasn’t so bad! 46% later at 1.99GB of the retrieval process I received two fatal errors that looked similar to file system errors. I then did some Googling to find that msysGIT only supports repository’s up to 2GB. The answer on the forums for this problem was, “have a smaller repo”. This is a problem, so I head back to the GIT homepage, where I find that the only real lasting option is to use cygwin GIT. 

After I get cygwin GIT all installed I finally get the repo fully downloaded I check to see if I can use the msysGIT to pull changes (which should never be 2gb worth), and it absolutely freaks out. So that’s not an option, and neither is adding cygwin/bin to your path because that complains about ‘exec ssh’ not existing.

Your probably wondering, why don’t you just use cygwin to do your GIT stuff? Well the issue is that we are using hudson to queue up jobs on the machines using the cmd environment to pull changes and run the tests in the repo. And it became very clear that the best way to handle this was to run the slave agent from cygwin, that way the jobs are actually running in cygwin land and this turned out to work — awesome!

To finish describing my pain, the last problem was that since I am running the tests from c:\main, (you have to be inside a git repo to pull and I want to keep these jobs simple) I am generating the log file in the wrong place, because the job looks in it’s home directory to find the jUnit Compatible XML results file. Fortunately there are some environment variables that I can use to get the files back where I want; mv *.log %WORKSPACE%

Now that life is back to normal and I’m getting used to living in the new GIT world, I can get back to important things like making Windmill more awesome and increasing test coverage.

Cheers!

Working up to the Windmill 1.0 Beta 1 Release, I finally had the opportunity to put some time into making the IDE (that a lot of you live in when in test writing mode) a little bit nicer to look at.

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.

Project Status

I have spent nearly every day since July 7th working to bring the Windmill Project up to a level where it can be used reliably in a production environment. Our mission starts with “Windmill is a web testing framework intended for complete automation of user interface testing”, of course this refers to the web including everything and anything inside the browser window. This turns out to be a very large task, one that only an Open Source labor of love could possibly attempt to accomplish.

Windmill has slowly evolved as a project with user contributions, a moderately active IRC channel, and enough users to keep me from forgetting what a useful and powerful tool it is. When I was offered the opportunity to work on the project I quickly saw how much needed to be done in order to get to where we needed to be. We still aren’t quite there, and like most Open Source projects we might not ever get to the envisioned perfection, however recently we hit a very important milestone. The project is now fully hosted and run by the committers, and in many ways “Grown Up”, thanks to a lot of good advise and hard work. The milestone we have reached, is that Windmill is ready for YOU to use. This week we pushed 0.8.2, which is a release that has addressed all of the major issues that we know about and have discovered with heavy usage over the past months. Our hopes are that you will go install Windmill 0.8.2 and things will just WORK. If not, I can’t wait to get your issues in trac and see what we can do to fix them.

Priorities

The main things we care about when it comes to our web testing tools:

• Low barrier to entry, low learning curve, and ease of use
• Thorough documentation, community and project support
• Support for the big 3 platforms; Windows, MacOSX and Linux
• Support for the big 4 browsers; Firefox, IE, Safari and Opera
• Easy integration with continuous integration tools
• Reliability; developers aren’t going to pay attention if the failures aren’t real
• A really nice looking logo, and a web site that is easy on the eyes..

There are always more features to implement, but Windmill hasn’t needed new features for a very long time. What Windmill needed was some serious QA, some code cleanup and a whole mess of bug fixes. If you look through the Trac Timeline you will see the massive amounts of all of the above that have happened and I am proud as hell when I launch the application today and see all that it can do.

What can Windmill do?

Windmill offers the ability to build, write, record and run tests as well as aid in debugging and development. In addition, the framework provides the ability to create and maintain hierarchies of smart and thorough tests that will ensure the quality of your web applications over time. Not only can we save you hours creating and maintaing tests, but we can also help you see your web application as a growing feature rich product, instead of a QA nightmare.

Many tools out there provide ways to write tests, some even provide recorders and DOM explorers, but none that I have ever seen provide this rich functionality cross platform and cross browser, which is really what is required in order to build a thorough test repository that represents all your possible users.

The current set of major features can be found at the Windmill Features Page as well as more details about what is currently available. One of the more exciting new features is the full integration with Firebug Lite. Web developers rely on the existence of Firebug in order to quickly build and debug web applications, and Firebug Lite is the next best thing. It’s hard to even describe how useful it has been to instantly access the JavaScript Console and DOM inspector in IE to debug a failing test. As the Open Source community grows, and tools are improved and brought to light, I think it’s very important to do everything we can to utilize these tools and use them to enhance the Windmill Framework.

Keeping it Open

The Open Source aspect of Windmill has turned out to be it’s greatest asset. The project is almost entirely written in JavaScript and Python, which instantly gives us many advantages over the competition. The JavaScript community is constantly evolving and is most certainly the futures technology platform. Python has a very strong community as well and has given us immense amounts of functionality and flexibility right out of the box.

One of the most exciting things to me personally about this particular project is the immense potential user base out there, and the large impact the Windmill Tools can have on the daily work flow of it’s users. Windmill was obviously inspired with the hopes of minimizing the need for manual testing of rich web applications, and has grown to be much more than that.

The future of the work to be done on Windmill will primarily be driven by the needs of it’s users, the changes and development of the industry and the success of it reaching the goal, to make web automation better.

Moving Forward

Concluding this major push of work, testing, documentation and moving of infrastructure; we now need to see how the community feels. There are lots of choices out there for web automation and we have made many differentiating choices along the way. It is now time to get the word out and take in some real feedback.

Thanks you all for input, contributions, patience and valuable feedback. Those of you who spent many hours on Freenode in #windmill with us debugging and hunting down those spastic blockers are troopers and we really appreciate it.

A large part of the utility in a testing framework like Windmill is the ability to interoperate with a continuous integration environment. Much of the work that has gone into Windmill recently has been the result of continuous integration needs. There are many ways to do this with existing software packages out there that include Tinderbox,Buildbot and Cruise Control however we picked Hudson as a result of the super small learning overhead and amazing simplicity required to setup slaves on the network.

One of the requirements of course for parsing results is the need for JUnit compatible XML output from the Windmill test runs. I don’t claim to be a Python wizard, or a XML/Java wizard for that matter but it wasn’t that painful to hammer out a function to generate some minimal output to get the process off the ground.

I would love to get a wiki page up on Get Windmill to start documenting the many ways to use Windmill in a continuous integration environment. So let me know if you have a working setup and would like to contribute.

Example Reporting Excerpt from __init__.py:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

from functest import reports
from datetime import datetime
 
class JUnitReport(reports.FunctestReportInterface):
    def summary(self, test_list, totals_dict, stdout_capture):
 
        total_sec = 0
        for entry in test_list:
            time_delta = entry.endtime - entry.starttime
            total_sec += time_delta.seconds 
        out = '<?xml version="1.0" encoding="utf-8"?>\n'
        out += '<testsuite errors="'+str(totals_dict['fail'])+'" failures="'+str(totals_dict['fail'])+'" name="windmill.functional" tests="'+str(len(test_list))+'" time="'+str(total_sec)+'">\n'
 
        for entry in test_list:
            if entry.result is not True:    
                entry_time = entry.endtime - entry.starttime
                out += '<testcase classname="'+entry.__name__+'" name="'+entry.__name__+'" time="'+str(entry_time.seconds)+'.'+str(entry_time.microseconds)+'">\n'
                out += '<failure type="exceptions.AssertionError">\n'
                #out += str(stdout_capture)
                #until I can figure out how to get the traceback
                out += 'There was an error in '+ entry.__name__
                out += '\n</failure>\n'
                out += '</testcase\n>'
            else:
                entry_time = entry.endtime - entry.starttime
                out += '<testcase classname="'+entry.__name__+'" name="'+entry.__name__+'" time="'+str(entry_time.seconds)+'.'+str(entry_time.microseconds)+'"></testcase>\n' 
 
        out += '<system-out><![CDATA[]]></system-out>\n<system-err><![CDATA[]]></system-err>\n'
        out += '</testsuite>'
        f=open('continuous_test.log','w')
        f.write(out);
        f.close()
 
reports.register_reporter(JUnitReport())

Happy automating!

I have added a windmill-dev category to the site which will not also get picked up by getwindmill.com. Mikeal and I are both going to be aggregating Windmill specific posts to the Get Windmill blog, if you or anyone you know is using and writing about Windmill please let us know and we can talk about adding your feed to our syndicator.

There has been a lot of cool stuff going on with Windmill in the last month, expect a very long winded entry from me explaining the state of everything in the next few days.

This year was my second year at OSCON in Portland, and it’s pretty amazing for me to look back at last July and know that I was working at OSAF. A lot can happen in a year, but what didn’t surprise me was the amount of people that I interacted with at the con that I had met during my OSAF experience.

A few things come to mind when I think about the conference as a whole. First off, who gave OSCON a Ruby adrenaline shot? The Ruby track was pretty extensive, and I would say more prominent even than the Python track this year. I felt like many of the talks were very introductory with very few actual visual demo’s of things “working”. I know that OSCON brings a very diverse crowd.. but please, please come up with some way to show us if things are advanced, or not. I really get absolutely nothing out of introductory level JavaScript sessions, but a title like “Digging into the guts of JavaScript” could pretty much mean anything under the sun.

Some of the most interesting talks I attended last year had to do with open mapping and location services, I know you want us to also attend the “Where” conference, but these things are part of Open Source and should be represented at OSCON!

I really enjoyed the talk about CouchDB, I hadn’t heard about it and really enjoyed how it opened my mind up to some new concepts about how your application should interact with a database. I would advise everyone to check it out at http://incubator.apache.org/couchdb/.

Another was the “Django Tricks” talk, this was great because he just ran through a bunch of really cool examples — one of which was introspecting a sqlite db to build models from the schema. Pretty cool stuff! Additionally, I think Ted Leung nailed his talk about “Open Source Community Antipatterns”. A lot of the ideas and concepts weren’t new to me, but it always helps to get a more detailed overview from someone who has seen these patterns repeated over the last 10 years.

The best quote I heard was that the “Second OSCON starts at 6pm each night.” I completely agree with this, the social aspect of the conference is invaluable, but be careful about all those free booze — they sneak up on you if you aren’t careful.

I do feel as if I should have done a Windmill talk this year, I didn’t see anything from Selenium or Watir and if we had been a little farther a long with the next iteration on Windmill it would have been a great venue to get some serious exposure. I may attend some other conferences this year, or wait till OSCON next year for Windmill to make it’s big splash.

What happened?

As some of you may have heard, today I resigned from my position at Rearden Commerce. Leaving a company is never a fun thing, because you know how you feel when you hear that someone else is leaving.. and you can see it in people’s eyes. I have reminded myself multiple times today that I am still going to be 30 mins away, most of my communication with those people has been via email and IM and there is no reason for me not to stay in touch.

Why did I resign?

That’s a very good question. Let me preface this by saying that I really don’t have anything about Rearden that I can point at and say ‘this thing’ is why I left. Rearden is a great company, they were professional through out my entire experience there. They employ many very talented and driven engineers, and they have a great product. My gut feeling after spending some time there, is that they will do very well. The management team is very skilled and they know their market and niche extremely well. Every day I went to work I heard about a new major deal or a small company Rearden had acquired to contribute to their march toward owning the ‘Personal Assistant’ space.

When I first arrived there I struggled with two things, and ultimately wound up being my demise as an employee. I have an extreme passion for Open Source, being part of that community, and giving my time to contribute. So you are probably thinking, ‘Why didn’t I just do that on the side?’ — well the answer is that I did do it on the side and the results were slow and my sleep schedule paid the price. Rearden has a very business/enterprise specific niche at the moment, and building and deploying new features to those customers is a priority (as it should be), but I couldn’t stop my Open Source envy. 

Secondly, a overwhelming majority of their user base is using IE6. As a web developer — the last thing I do when building anything in client side JavaScript is to test it in IE6. I basically hold my nose, load the page and pray that things ‘mostly work’. Now I’m not going to claim that I can ever get away from doing this, but building really cutting edge features based on new technology becomes significantly less probable when you are catering to this crowd. I know that Rearden has some really cool future plans, and is publicly talking about bringing the application to the consumer market — but I’m impatient and I just simply didn’t want to wait.

What’s Next?

I am going to jump right into a gig with Slide Inc. as a Web Developer. However, before I get to any Web Development tasks I am going to be addressing a pretty serious need they have in their QA department. Slide currently has many applications that are used directly on their site, slide.com and on social networks (primarily facebook.com and myspace.com) and right now they have essentially no functional automation.

At OSAF I saw what a major difference automated testing can make, and the reason I am so excited about this is because I was a QA Engineer at one point manually testing a pretty complex web application (Cosmo) and I have seen how much a difference test automation can make in the release cycle, the development cycle, QA test cycles and simply the daily lives of your poor QA teams.

How am I going to accomplish this task you might ask? Thats the best part — I have fixed about 10 bugs in Windmill in the last week, and will be putting whatever effort is required into getting Windmill to a state where we can functionally automate all of Slides application testing. This looks to be a serious win for Slide, and a serious win for Windmill. 

At some point in the future, when I feel that this project is to the point where it can be maintained and built on by the Slide QA teams I will move on to Web Development tasks. At that point a smaller amount of time will still be allocated to maintaining Windmill, adding new features that Slide and the community need and working towards the next evolution of Windmill. That is quite a ways off in the future, so I will address all that when the time comes.

The rest of my ‘free’ development time, will be consumed by a project that I am involved in with the Mozilla Corporation. This project lives in the QA realm as well, and could probably be classified as a distant cousin to Windmill. More details about that will be announced the week of OSCON, so keep your eyes pealed.

Change can be extremely tough, but it is also very exciting. I want to thank all of my former peers at Rearden for a good experience, and I wish them all the absolute best.