Choosing Tools

A common first reaction is to take a couple of those old boxes sitting around to run the first “couple” tests you have. In some cases, this is the perfect solution. That is if you have a small application that rarely changes and only needs a daily test run (on one operating system and it’s available browsers). In my experience you can reasonably run one Windows VM without lagging the host machine unusable, which gives you two concurrent browser test jobs without worrying about process conflicts. Do remember that to do this correctly, you really want a machine dedicated to your CI system (which I will talk more about below).

VM’s are a great solution, however they require significant hardware overhead, continuous attention and licensing costs. Depending on the VM solution you choose you may also wind up dealing with the dreaded VM Time Drift causing problems with JavaScript and failing tests that aren’t actually failing.

“The Cloud”, is the 2009-2010 buzz word that makes all technology sound better, and in a lot of ways COULD be the ideal solution for test automation. You get the benefits of paying for only the cycles you use, having someone else manage the infrastructure and avoid those pesky licensing costs. However in my experience the setup is painful, the solutions (EC2, etc.) are slow and lacking some of the features to really do test automation well. For example, if you want to run your own CI instance and run your tests on demand in the cloud you will run into some pretty painful engineering problems. It’s not easy to instruct the “cloud” service to fire up a Windows VM and then have that VM connect to your CI instance and become an available slave. It’s doable with Linux, but last I checked – the features to do something similar with Windows simply weren’t there. Also do you really want to wait sometimes up to 15 minutes (also my experience with EC2) for the machines to come up before you can even start running your tests?

What CI System?

The point of this article is not to recommend solutions, it is to encourage questions. However, outlining all of the possible CI systems would take forever so I will simply say that I wound up using Hudson. The reasoning includes a very open and functional Open Source community, with smart contributors willing to take a few minutes to respond and help me out. I also found it possible (not simplistic) to build plugins to customize the things that I needed changed. Many people out there swear by Cruise Control, or Build Bot and I would highly encourage you to do some research and pick the solution that you feel will allow you to be the most productive. For example if you plan to use Windmill and EC2, you may want to do some reading about the Amazon EC2 and Windmill plugins available for Hudson and see what comparable tools are available.

Which test framework?

Some of you may know that I hold a mild bias when it comes to this question, but over the last year and a half I have ventured out into the land of testing frameworks and am able to see the values held by the other projects. For example, if you don’t ever need to deal with JavaScript in your application (or have browser specific functionality) — I suggest you use a tool that doesn’t require a real browser (like Twill). Tests will run faster, they will be more stable and can be run without access to your OS’s graphics layer.

When it comes to browser based web testing tools I really think you need to pick the one that fits your needs the best. A great example of this was in my needs to automate functionality contained in iframes being served over HTTPS from a different domain, the only solution (after weeks of trial and error) turned out to be WatiN. Of course, writing and building tests in C#.net wasn’t going to be an easy sell so IronWatin was invented as a means to write WatiN tests in Python.

Watir has captured a lot of the Ruby community and has recently been moving towards consolidating the separated browser  projects into one, which will significantly improve the ease of use.

Windmill has a dedicated community, focuses on dynamic JavaScript applications, boasts lots of features and goes for an ease out of the box type of experience.. at least that’s what I would like to think! Please feel free to check out the destination site or Github wiki for more information

Selenium has a thriving community, lots of available consulting support, integrates well into a Java environment and offers the Grid project. You can also avoid all of the work involved in running your own system by writing your tests in Selenium and then offloading them to a company like Sauce Labs if you are willing to pay for it.

What do we do about Flash/AS3 automation?

After unsuccessfully trying out FlexMonkey and AsUnit (don’t take my word for it), Matthew Eernisse sat down and wrote an AS3 test controller that works the way the rest of test automation works in the browser, it’s part of the Windmill codebase (codenamed FlashMill). There are two ways to run the tests, one is to hand FlashMill your tests already written in AS3 and the other is to write them in your favorite tool (or raw JavaScript) and have them call into the FlashMill API. Windmill currently has full IDE/UI integration in master to be released soon, the integration code is simple and can be viewed here (best doco at the moment until I write a better one).

Workload

Depending on the machine setup you are going with, this will vary. Obviously if you have a box and a VM on it you can manually go through the process of upgrading the browsers on each, installing patches and security fixes for the OS etc. But if you went with the VM solution, you need to come up with a way to deploy updates to all the machines in your pool. An Open Source solution that came up near the top of my search is WPKG, but like the rest of the tools on this page – there are many solutions and you will want to do your research. Some of the maintenance you will be dealing with can be done as a system job, or run by your CI system. A good example of this is to remove data, test files, source repositories etc. that accumulate on your test running machines.After a while, these files in combination with temporary internet files from the browsers and system tmp files start to slow things down.

This piece is very important to take into consideration from the beginning, because once you have 15 VM’s running tests — doing anything manually becomes a major chore. You also need to be cognizant of that fact that if you chose the cloud testing solution you will be managing your own test running images used to boot the VM’s. Every time you want to make updates or changes to that image, you get to go through the whole process of baking it and uploading it to the cloud hosting service. In my experience, this process is NOT enjoyable or quick.. so be prepared to invest some serious time.

What is the strategy for scaling and expanding?

Clearly this will be dictated by the rest of decisions you made, but I think when you get to this point, the idea of buying and manually setting up more and more physical boxes starts to break down. Buying more and more machines to sit there running tests simply seems like a bad use of resources (and desk space). VM’s allow you to quickly replicate images and expand your arsenal as long as the host machine has the hardware resources to power it without negatively effecting test run times on all the others. There are also solutions out there that allow you to boot and shutdown VM’s on the fly, which provides some interesting possibilities in juggling system resources.

I have found that since Windows is the common platform that can run all the browsers I care about, having a large pool of identical VM’s running all the time is an easy way to queue up 100’s of tests and get results in a reasonable amount of time. I do think that this is the aspect that cloud services start to become more appealing. The idea of spinning up more and more virtual machines in the cloud (with essentially endless capacity) makes the idea of scaling those tests considerably less terrifying. If you can get over the generally slow spin up times, and have come up with a strategy of dynamically harnessing and adding those machines to the pool – you may have it made!

What format/language is best for our tests?

At this point in web testing you simply need to decide what you care the most about doing. Is it manipulating the page? Or is it interacting with a database?, or a little of both? If you can get away with writing your tests fully in JavaScript, I would recommend it. At least in Windmill the JavaScript tests run exponentially faster than the Python or Ruby tests do. However the libraries for communicating with databases, email, system services etc, may make Python, Java, C#, etc your ideal solution. Each of the tools has their own ways of doing things, and to come up with the ideal language really depends upon your system, what your test developers are comfortable with, and what your application platform looks like.

What operating systems and browsers do we need?

The answer to this question should come from the metrics of your user base, and will also help you narrow down a testing framework and your test machines. Some of the available frameworks simply won’t run on Linux, or support IE6. Are all your users using Google Chrome? Then you should probably make sure the test framework you use has a Chrome launcher. Historically I have concentrated about 90% of the available VM resources on the most popular platform (usually Windows), with the most popular browsers (Firefox latest release, IE 7 or 8 depending on the users, Safari Windows latest release, and Chrome). This gives me a pool of work horse machines that can crank out tests representing the majority. The other 10% would be divided into the higher percentage minorities which probably includes a MacOSX slave running FF and Safari and a Linux machine running FF and Konqueror.

Methodology

I have found that having your own test infrastructure really makes this one easier. Since your resources will probably be on the same network as your codebase, you can easily access and run unit tests.. however as soon as you start sending your tests off to the cloud you are dealing with some security/privacy issues and engineering challenges. If inorder to unit test your code you need the entirety of your code base available, sending a copy of it off to your image on the cloud for every test (job, run or even change set) over and over could become a major strain on your system and simply sounds like a bad idea. If you are counting on unit tests you will at least want a machine on your network available as a slave from the CI system for those jobs.

How do we report results, and stay tuned into failures?

Most CI solutions have many ways they can be configured to alert you of a failure, from email, irc, jabber to a phone call you can usually find some solution that will get your attention. At this point in time the norm appears to be jUnit compatible results in XML. I’m not a huge fan, but the available tools for parsing and aggregating jUnit into something useful is very appealing. If you are okay with a true/false, that will always work out of the box, but you will need to be prepared to put in a little extra effort in both your test development and test job setup to generate the jUnit report files.

What role does automation need to play in our process?

For maximal results you need to make the leap where QA and Development both understand that a failing job in the CI system is a show stopper and must be investigated immediately. This way people honor the continual nature of continuous integration. It’s job is to catch problems shortly after they are broken, point you directly at them, and continue failing until you have solved the issue or fixed the test. If this isn’t the process you want, having continuous integration may not be the solution you are looking for.

Another effective strategy I have seen is to base release viability on the status of your CI system. Don’t let the product go out the door until the ‘thoroughly defined’ suite of functional and unit tests running in continuous integration are all running and passing. It is easy to push off the process of updating failing tests until “later”, but everyone is busy, and later is usually never.

What part of our application should we automate?

This really should be computed by time and resources, as much as I would like to say “everything” I am well aware of it’s low probability. Pick your application flows that make you money, or really mean a lot to your users likely experience. Ensure that your application loads, they can take the happy path, give you some money and then leave. At least this way you can sleep at night knowing that, they may not be able to change their profile information but they can still pay your salary.

Conclusion

Here is your answer, and it is now easier than ever.

1. Go to: http://jqueryui.com/themeroller/ and create your theme (or pick a pre-defined one)
2. Download and unzip the file. (it doesn’t matter what you select for jQuery components)
- On a mac you will find something like this: jquery-ui-1.7.1.custom.zip Folder
3. Open the contained CSS folder there will be another folder, currently windmill uses “smoothness”
4. Find windmill/html/css folder in the windmill source directory
5. Copy the specified folder in step 3 into this folder
6. Edit windmill/html/remote.html, line 10 to read like the following:

1

<link type="text/css" href="css/*your folder name*/jquery-ui-1.7.1.custom.css" rel="stylesheet" />

7. Load windmill!!

Here are a couple examples of pre-defined themes I tested out.

Humanity

UI Darkness

Happy skinning.

The combination of writing content style HTML, and the good advice we received have come together into what I feel is a pretty usable user interface. Granted this is the first revision and will probably continually be refined to become even more user friendly, but from 1.0 to 1.1 it is a vast improvement.

Improved Editor

The first major improvement is the implementation of a full featured code editor named EditArea.

We have been keeping our eye on Bespin, which we will look more into integrating when it is a bit more modular.

For the meantime EditArea does a great job, and was *relatively* painless to integrate.

Some of the features include:

• Multiple file editing
• Syntax hilighting
• Full Screen mode
• Adjustable font properties
• Jump to line numbers
• Search and replace
• Automatic tabulation
• Toggle hi-lighting
• Toggle edit modes

EditArea implements execCommand similar to the implementation in Midas.

Reorganized Menu’s

Part of the move from XUL involved no longer relying on the toolbox, so we have reorganized the menu’s into dialog’s (don’t worry most functions have a keyboard shortcut if you are one of those people that doesn’t want to deal with that extra click).

This cleanly displays all the available options, and doesn’t clutter up the main UI. This also provides space to easily add new features that fall into these logical spaces in the future.

Improved Inspector

There was a lot of frustration when it came to getting the results from the inspector into the editor, some of this had to do with the non editable default nature of the elements we were using to draw them out in XUL, but the integration of the feature into the IDE became very messy and confusing.

This creates an obvious separation between the rest of the UI and the inspector feature and puts helper features out in front of you to simplify the process by dumping to the clipboard and then moving you to a focused editor window.

Improved Output

The output UI has been completely revamped to give you the most important information quickly, but allow you to navigate down an expandable tree to explore the output of the exception.

All of the information in the output divs can be easily selected and copied to stick in bugs etc, but also saves you a trip to the error console as it should encompass all of the information being thrown in the error object, serialized and organized into a more readable format.

Thanks to JQuery UI’s information and error boxes I was able to tweak the CSS to make some relatively attractive, but more importantly, informative UI that should quickly give you the status of your test run.

More Information

• MozMill Google Code Project
• Mikeal Rogers Release Blog Post
• Google Code XPI Download
• QMO Documentation
• MozMill on PyPi

Thanks everyone who logged bugs!

I don’t necessarily want to bookmark these sites, and this process of opening them is somehow part of my routine, however spending this kind of time every time I want to get to this state is just silly. Part of the ritual is to go through each of the open tabs, read the most recent updates and then close the tab, repeating this whole process many times a day.

At this point you should be starting to get the jist, to automate this whole process I created a Firefox Extension called MyTabs. The UI and use case is simple, but some of the tools I built in make it potentially very powerful.

MyTabs has the MozMill Controller built in, and is automatically setup in the tabs content window scope, allowing you to write and attach scripts to each tab to be executed ‘onload’. Thus automating the need to ever manually login to your web applications again.


Example script for logging into Facebook:

1
2
3
4
5
6
7
8
9
10
11
12
13

//Lookup the three elements I want to interact with
var email = new elementslib.ID(doc, 'email');
var pass = new elementslib.ID(doc, 'pass');
var login = doc.getElementsByClassName('UILinkButton_A')[0];
 
//Controller expects elementslib objects
var elibLogin = new elementslib.Elem(login);
 
//Tell the controller to type the credentials
tab.type(email, 'my_facebook_account@address.com');
tab.type(pass, 'my_password');
//Click the login button
tab.click(elibLogin);

This is all possible by a really slick snipped of code I found on MDC:

1
2

var newTabBrowser = gBrowser.getBrowserForTab(gBrowser.addTab("http://www.google.com/"));
newTabBrowser.addEventListener("load", function() { newTabBrowser.contentDocument.body.innerHTML = "Stuff"; }, true);

Security/Preferences

For the sake of security I made it so that you can only attach scripts, not edit them so that you friends can’t go and view your script to get those plain text passwords. All the tab data is stored in the prefManager so that it is available across sessions. However if someone knew enough to pick apart the source, install a trusted JS Shell and manually access the prefManager you may be in trouble… so be careful about super sensitive information especially on a shared machine.

Using jQuery UI I was able to make the UI relatively attractive, intuitive and possibly skinnable in the future (if you want to do this yourself, grab the source swap out the jQuery UI theme CSS directory and boom you have yourself  new look.)

Some Screenshots

The source is fully available on GitHub, and the XPI is available on Mozilla Add-ons.

• MyTabs on GitHub
• MyTabs on Mozilla Add-ons

Remember that I am currently on bug fix release 0.3, but please let me know if you run into any problems!

Since making things looks really nice in XUL is really hard, I decided that I would build the UI in the current Firefox content window (sorry tbird etc, but I built a less shiny version of this into Mozmill trunk for all of you).

Some of the functionality that I decided was a top priority was some slightly abstracted access to the window mediator which I am calling ‘windows’, and is simply an array of all the different windows available in the whole browser. The other big one is dir(), I am constantly looking for a property in one of the many, many objects I am trying to access and now that is really easy.

All of that goodness combined with enough space to stick real code blocks and a full history (which you can access using the shift key and up/down arrows), I find myself pretty comfortable.

After installing the extension, you can simply press ‘meta (cmd on mac) + shift + s’ and you should be greeted with the following (toggling will show/hide the shell):

UPDATE: It was pointed out to me that on windows meta may not be bound, so I have updated both the extension and git, please try ‘alt+shift+ctrl+s’ or ‘ctrl+shift+s’ on windows/linux, (I am testing in a VM so it’s a bit strange. Sorry about the confusion!) 

Welcome to XUSH

To get started, you can type ‘help’ to see what is available to you.

Help Menu

Other available functionality includes a big chunk of the mozmill controller for driving user actions in the browser, as well as elementslib — which gives you all kinds of powerful features for looking up nodes in the browser.

ElementsLib

As I mentioned above, the windows helper can quickly give you an idea of what is open in the browser and let you directly access the objects in the windows[x] array.

Windows Helper

The nice big console gives you enough space (and using shift) you can do multiple line commands to actually execute code snippets:

Code Blocks

My next round of features will include some more helpers, including tab completion and any bug fixes I find, please let me know of any that you find!

If you would like to play with the source, I have it on github and have a python script that uses mozrunner to launch it in dev mode (with venkman installed, although now I don’t really need it), but saves you from installing and uninstalling the extension every-time you want to try out your latest code changes:

python xush.py


That should launch Firefox with XUSH and Venkman both installed and allow you to hit the shortcut and wham, test away.

After another round of bug fixes I will be submitting this to Mozilla AMO.

Other projects you might be into if this interests you:

• Venkman
• Mozmill
• Chomebug

Thanks for your interest!

The following list are the different options you have for looking up your node:

• link
• xpath
• id
• name
• value
• classname
• tagname
• label

Keep in mind that we iterate all iframes we can access in the window if the node isn’t found in the page document. lookupNode takes an object, like so:


var myNode = lookupNode({id:'myNodeId'});


The very interesting use case we had today was the need to access and parse data from a link on a page in a Python test, I believe the final result looked something like the following:

url = client.commands.execJS(code="lookupNode({link:'Link Text'}).href")["result"]
#url parsing in python goes here into needed_value
client.asserts.assertValue({id:'mycheckbox', validator=needed_value})


lookupNode in Action

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.

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.

For years now, we have had to ’suck it up’, and pour a glass of scotch to get through an afternoon of testing in IE. As I am now a Web Developer at Rearden Commerce who currently caters to an audience of enterprise users instead of your standard bay area geek population — I have to make sure everything I commit works nicely in IE.

Last week after a few hours of IE testing, and dirtying my code I worked so hard to perfect and refine with alerts everywhere I decided that there HAD to be a better way to do this. I went ahead and spent many hours searching the web, installing everything I could find that promised to make IE development easier and happily I can say — it was a success.

First and foremost however, there are a few tips I can give you right off the top that will make your life easier. Before you take the plunge into line by line alerting, go through your code and do the following;

* Remove unnecessary commas in your data structures:

( FF ignores this one, but IE will give you an error that isn’t helpful )
ex.

var superNinjaObject = {
me: 'adam',
home: 'oakland',
};

* Don’t try to access characters in a string as if it was an array:

( Works in FF, but IE will simply give you undefined and not tell you a thing )
ex.

var myString = 'Welcome to the Jungle';
$('mynode').innerHTML += myString[14]; //Broken in IE
$('mynode').innerHTML += myString.charAt(14); //Compatible alternative

Now we can get to what you are really interested in, the new tools:

1. Internet Explorer Development Toolbar

Get It: Microsoft Downloads

This is Microsoft’s best stab at a firebug equivalent. This gives you all the flexibility you need to inspect the DOM tree, look at CSS, Scripts, Images, Network etc. To put it simply, it makes IE development something you can swallow. I can’t image going back to IE development without this. Unfortunately it is missing two things, the first is the absolutely necessary JavaScript shell. This can be solved by using the IE JS Bookmarklet that you can find at blog.monstuff.com. Add this to your favorites and then whenever you need a JS shell, pop this up and hack away ( I agree it would be nicer if it was built in ). The second is the ability to set breakpoints and step through your code debugging and introspecting objects and variables. I do have a solution for this, see new tool number

2. Visual Web Developer 2008 Express Edition

Get It: Microsoft Express

This is the solution to your break pointing, stepping, introspecting needs. The way you use it is a bit awkward, but it does complete the development experience. To use this you need to create an empty web project and then start debugging. This will launch IE and bring you to a blank server page off the local MS web server instance. At this point you can go ahead and plug in the URL of the app you are wanting to test. Additionally if you have set any ‘debugger;’ statements in your source it will pick that up and automatically ask you if you want to start debugging there, or continue on. When you stop the debugging session in VWD it will kill your browser, so beware if you have to navigate to some deep point in your app you are probably going to get frustrated if you write buggy code. At it’s 1.4 Gb space requirement it’s hardly a comparison with firebug — but it’s certainly a step up from alerts all day long.

3. Microsoft Script Editor

Get It: Jonathanboutelle.com

If you don’t already have it installed, a good midpoint between nothing and Visual Studio Express is the Microsoft Script Editor which comes with office 2003, heres a video on how to use it, Video. Thanks for the feedback blogosphere.

I hope this made your life at least a small amount easier, happy IE developing.