Scott Hanselman

Time Saver - Using Watir as a Startup Program in your ASP.NET Projects

July 21, 2006 Comment on this post [10] Posted in ASP.NET | Ruby | Watir | Bugs
Sponsored By

Often when you're inching forward within an ASP.NET project you'll find yourself repeating actions over and over again to get to a certain page, often three or four actions in to the application. As someone who hates repetitive actions this is what I do.

(These examples are in VS2005, but will work in VS2003, although the property dialogs have changed)

I use Watir to automate the clicks that will get me to where I'm going and set my Watir script to startup when I press F5 to start my project debugging.


In this example, I have a script called justsignon.rb that signs on, visits the customer's accounts page, then goes to their Account History page. It's that page that I am currently debugging so I want to automatically show up there in a certain state when I start debugging.

require 'watir'

include Watir

require 'test/unit'

class WatirMakerRecorded < Test::Unit::TestCase

    def test_recorded

        ie =



        ie.text_field(:name, 'userTextBox').set('testuser1')

        ie.text_field(:name, 'passwordTextBox').set('123456')

        ie.button(:name, 'signInCommand').click, /Hanselman/).click, "Account History").click

        #UPDATE - the debugger will detach if the spawned process ends, so wait for ENTER





As I move forward in my development process I use different scripts to get me to different states.  This easily adds up to as much as 15 minutes to a half hour of rote "monkey clicking" that is usually wasted time.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
July 21, 2006 4:32
That works. I usually do all my web development in Firefox. When I need to debug a page, it is usually already up in said browser. Then, I simply hit F5 in Visual Studio to start the debugger. Internet Explorer launches, desperately trying to get my attention. But I'm already back in Firefox, trying to solve my problem. Poor IE. So lonely. I almost feel sorry for it.
July 21, 2006 4:35
Aaron - Don't forget FireWatir...;)
July 21, 2006 7:16
I combine a couple of tricks to ease debug startups.

First, I use the Session State Server Service during development (and in Production). In development, I point web.config to use my local machine as the session state server. This allows my sessions to be retained when I rebuild, so long as I use the same browser window.

Second, I never hit F5 to start debugging. Rather, I hit Debug->Processes... select aspnet_wp.exe, Attach, OK, Close. This attaches the debugger to the already-running worker process. Then I just go back to my already-open browser (IE usually) and continue what I was debugging. Now, this part sounds painful, but... I have Alt-P mapped to fire off the 'Processes' command in VS.NET. And most often, aspnet_wp.exe is the first item in the processes list, and it's already selected. When that's the case, I simply need to press Enter 3 times (as quickly as I can), and I'm set. Bastard acrobat sometimes steals the #1 spot, causing me to hit the down arrow once in the middle... but I can hit Alt-P, Enter, Enter, Enter very quickly and viola-I'm debugging.

I don't remember the last time I used the traditional Debug->Start process for debugging an ASP.NET project.
July 21, 2006 10:51
Nice one Scott!

I've taken the liberty to mention this post on my poor-cousin of a blog (!)
Don't know how you do it, and do it, and do it....

Mitch Wheat
July 21, 2006 18:40

I already use SlickRun with a few choice commands set up for most quick debugging. Making a separate command for editing the rb file makes it really easy to keep updated. It makes logging in as different users and going different places really easy.

I also use Watir and unit test cases for more involved debugging. That allows me to put assertions in while getting to the page I want, and I can keep it if it ends up as a useful functional test of the fix.

This takes it to the next level by making it that much faster to compile and run.
July 24, 2006 16:20

I think you may have one little issue with this snazzy Watir script. Once the ruby script completes, doesn't the ruby command window close and disengage the debugger automatically?

I'm running a similar script in VS2003, and I ended up putting an extra "gets" statement at the end of my script so that I could keep the debugger attached to the process.
July 25, 2006 14:04
Sweet! What a great tool.

Although having some problems, setting it up as that, ruby runs but never executes the script and the command window disappears too quickly to see that the problem is. Any help?
July 25, 2006 14:09
I "think" it can't find the ruby script file although it setup with the full path to the script. Am I missing something? Although this isn't the "correct" forum for this. ;)
July 25, 2006 20:25
Ray - Remember to include quotes around long filenames.
July 27, 2006 3:06
Good stuff. Maybe instead of driving your testing through the browser, however, try extracting the thing you want to test into a host-agnostic class -- one that is easy to put into a set of NUnit tests. In other words, don't depend on the runtime and the browser interaction to get to the code that you want to test.

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.