As a follow up I have just uploaded version 0.4 of Watir WebRecorder which now has support for Divs and TDs which have onclick handlers.  It also displays a disclaimer on startup regarding its limitations and that any failure to record something is no reflection on the abilities of Watir.  I've also added a disclaimer to the Watir WebRecorder page on our site and have had the Macro Scheduler WebRecorder page modified to say "No Advanced Programming Skills Required" rather than "No Programming Skills Required".  I hope this goes some way towards satisfying any concerns.

http://www.mjtnet.com/watir_webrecorder.htm

Regards,
Marcus

On 2/16/06, Marcus Tettmar <[EMAIL PROTECTED]> wrote:
Hi Bret,

On 2/16/06, Bret Pettichord < [EMAIL PROTECTED]> wrote:
1. When i recorded a script i saw a lot of calls to IE#wait. I don't believe they are necessary in any of the cases i saw. In fact, my position is pretty much that users shouldn't have to make calls to IE#wait in their scripts. If they do, it is a bug in Watir. I'd suggest removing them and reporting any cases where they seem necessary to you as bugs.

In 0.3 under Tools/Options you can switch off "Insert Waits".  I have found that they are sometimes useful so I have made it optional.  At present you also need it to record/automate server auth logins.  Goto waits forever if a login box pops up because the page hasn't finished loading until after the password has been issued.  So there are options to use ie.navigate instead of Goto and therefore an ie.wait is needed after it.  But in the latest version 0.3 these things are optional.  So you can switch this off.

2. Not really a bug, but i think the "require 'test/unit/ui/console/testrunner'" is also unnecessary.

I'll check that out.

The other thing that is missing is support for Area tags.  While WebRecorder can record clicks on Area maps I couldn't find any support to play them back in Watir. 

True. I haven't seen much demand for this, so i don't think any one is working on it.

In the past I have had to automate web sites that used an Area for the navigation menu.  So it was necessary to record it.  But it is true that they don't seem to be that prevalent.
 

Regarding my views of recorders...

I think that recorders can be useful aids to programmers. But i think you need to know how to write and modify the code that is being generated.

I agree.

One problem is that recorders often lead people into thinking that they don't have to be a programmer to use the tool.

I'm not so sure.  I cannot be alone in using Microsoft Office's macro recorder to get a jump start on creating VBA code.  If I can't remember how to do something, or want to get the bare bones of the code from which to work I will nearly always record the main process with the VBA recorder.  But then I will tidy up the code and make changes to it.  I am very experienced in VBA yet I find the recorder extremely useful.  I am aware of many other VBA programmers who do the same.  At the same time the complete beginner can quickly build basic macros without knowing any code.  They won't get as far as the programmer but both are happy and both find the tool useful within the limitations of their abilities.   He knows that a programmer would get more out of it.

In fact, your website makes this very claim. This is what i object to. Not to recorders themselves.

In respect of the Watir WebRecorder I wasn't aware that we were making this claim at all.  In regards to Macro Scheduler's WebRecorder it is true that we say no programming skills required.  But this version outputs very different code and is for a very different type of user.  In terms of the code it outputs the people that use it don't need to modify it.  I can cite customers with no programming experience at all using MacroScript WebRecorder to create dozens of useful web automation scripts without really understanding the code it is creating.  So in their case I can stand by our claims.

A second concern is that it simply is much harder to make a reliable recorder than it to make a reliable execution tool. This is why Watir is an execution tool, only. The problem is that there are always all kinds of controls that a tool can execute against but can't record. For example, i tried to use WebRecorder against a random website that had some _javascript_ links (probably div tags, i didn't even look) and they didn't get recorded. I didn't even report that as a bug, because i didn't expect it to work. Every test tool i've ever used that had a recorder had more reliability problems with the recorders than the execution. I see them as two separate things. But that isn't the view of the non-programming user. To even understand the limits of a recorder, you have to know something about html -- in other words you have to be, in some sense, a programmer. Anyway, my point is that if i were to bundle a recorder (any recorder) with Watir, people would try it first, learn that it wasn't reliable and then conclude that Watir wasn't reliable. In other words, it would reduce the percieved reliability of Watir.

I haven't gotten around to creating a help file for the Watir version yet, but will do so soon.  When I do I can write in some caveats.  The MacroScript version explains that not everything can be recorded, but to contact us if they find anything that can't so that we can see if we can improve it.  Otherwise we never get to know about these sites and while we spend time looking at random sites we can't find everything.

As you say it is hard, perhaps impossible, to make a recorder for all web sites that will manage to record everything.  There's simply a limit to what the developer can think of to test and the number of web sites and the ways they work is infinite.  So far our users appear to be aware of that and let us know when they find something it fails with.  We are either able to find a solution and make a modification for them (and the product gets better) or we have to explain the reason why it can't be recorded.

Re the issue you found - possibly Div tags - Watir WebRecorder doesn't record Div tags.  MacroScript WebRecorder doesn't by default but has an option where you can specify extra tags you'd like it to record.  So it probably gets round this problem.  In time we could add the same sort of functionality to Watir WebRecorder if people are interested. 

If the recorder is a separate tool, that doesn't make any claims about allowing non-programmers to create Watir scripts, then i'm cool with it.

How about I add a big warning box that appears on startup with a big disclaimer saying that knowledge of Ruby/Watir is necessary and that the recorder has limitations and may not be able to record everything?

Am i being harsh with WebRecorder? The Watir WebRecorder page says "WebRecorder is designed to speed up the creation of web testing and web automation scripts." I'm cool with that. But commercial WebRecorder it is billed as "No Programming Skills Required". I haven't looked at this version of the tool, but i'm pretty skeptical about this claim.

As I said, I can stand by that claim just on the basis of the sort of people that are using Macro Scheduler and MacroScript WebRecorder.  That said while in many cases no programming skills are required, they do help!  Many people with no prior programming skills have used WebRecorder/Macro Scheduler to create pretty amazing scripts (but have gained programming skills along the way).

With Watir WebRecorder however, I would expect people using Watir WebRecorder to understand Watir/Ruby to start with.  I will try to make that clearer.

--
Marcus Tettmar

http://www.mjtnet.com/
Macro Scheduler & WebRecorder for Windows & Web Automation and Testing. WebRecorder for Ruby/Watir now available.

_______________________________________________
Wtr-general mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/wtr-general

Reply via email to