Scott Hanselman

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

July 20, '06 Comments [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.

Aspnetrubystart1

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.new

        ie.goto('http://localhost:4970/MobileDemo/default.aspx')

 

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

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

        ie.button(:name, 'signInCommand').click

        ie.link(:text, /Hanselman/).click

        ie.link(:text, "Account History").click

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

        gets

    end

end

Aspnetrubystart2

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
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web
Friday, July 21, 2006 12:32:15 AM UTC
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.
Friday, July 21, 2006 12:35:02 AM UTC
Aaron - Don't forget FireWatir...;)
Scott Hanselman
Friday, July 21, 2006 3:16:46 AM UTC
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.
Friday, July 21, 2006 6:51:50 AM UTC
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....

Regards
Mitch Wheat
Friday, July 21, 2006 2:40:34 PM UTC
Cool!

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.
Monday, July 24, 2006 12:20:00 PM UTC
Scott,

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.
Jeff Fritz
Tuesday, July 25, 2006 10:04:35 AM UTC
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?
Tuesday, July 25, 2006 10:09:18 AM UTC
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. ;)
Tuesday, July 25, 2006 4:25:59 PM UTC
Ray - Remember to include quotes around long filenames.
Scott Hanselman
Wednesday, July 26, 2006 11:06:05 PM UTC
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 asp.net runtime and the browser interaction to get to the code that you want to test.
Brian Windheim
Comments are closed.

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