Let me elaboriate on that.
If you are just creating some kind of quick and dirty automation, something
relatively speaking 'throwaway' then a recorder can be a useful tool. for
example recording interacting with a multi-setting UI so you can
parameterize and run a combinatorial test. Also useful if you need to get
a protocol level exchange for something like a loadtesting scenario.
But for most functional automation, a recorder encourages you to "just
record your manual tests" It provides a false promise of 'easy functional
automation'. The big problem here is two-fold (at least, I'll be others
can find additional folds).
Firstly, what makes for a good manual test does not make for a good
automated test. Manual tests optimize for making things easy for the
tester and reducing work duplication, they depend on at least a
semi-skilled tester who will know what to do if something goes wrong in the
middle of a scenario that is in essence a long chain of little tests. If
some particular thing is important to look at, the manual tester knows what
to skip over and how to set things up to look at just that one little part
of the scenario. But that's terrible for automation. For automation you
want small atomic tests that can be run in any order, are not dependent on
another test passing upstream. You want the tests to be able to run in
parallel if needed (to say test against 4 different browsers at once, or to
reduce the runtime of the tests). and if there is a problem detected you
want to be able to re-run the one single test that shows that problem, or
hand it off to a developer so they can use the test to assist with
debugging and validating their fixes. With automated tests you want to be
able to reduce duplicated code and have reusable code/steps etc You want
to be able to use abstraction layers to give you 'one place to update' when
your application changes. None of that is possible when you record manual
tests, instead of hand crafting your automated tests.
The second problem is that I've yet to see a recorder that was 'smart'
about how it identified things, well as smart as a human can be. This
creates very brittle tests, that require a lot of maintenance just to keep
running. When you create automation 'by hand' you can do something that is
the equivalent of "look in this table for the row that has xxxx in it, then
on the same row click the "update" link. That's something that won't break
if the order of the items in the table changes, or items are added or
subtracted. A recorded test is going to click on the nth link in the xth
cell of the third table.. in other words it has no way to replicate the
logic behind why you clicked that particular link. and that's just one
example. a lot of recorders use fully detailed xpath paths to an object..
one little cosmetic change to the page will very often break the tests
because the path changes in subtle and unpredictable ways.
Another other thing is this, they day in which a recorder was a useful
learning tool is IMHO long past. Browsers didn't used to have good tools
for identifying objects, examining the DOM, etc.. so there was a lot of
staring at raw html trying to find things and a recorder could be a useful
'trick' for finding elements in the DOM etc. But these days you have the
IE developer tools built into IE, you have Firebug, and you have great dev
tools in Chrome as well. All you need do now is right click your element
and pick "Inspect Element" (in chrome or firefox), or use a locater tool
('select element by click' in ie) to pretty much see everything you might
need to know in order to write a script that addresses that element.
Using a recorder is now actually a SLOWER way of discovering that kind of
information. And in these days of ajax, the browser tools can let you
actually watch the dom change when you do things like mouseover menus etc,
whereas my experience in using a recorder tool with ajax was always
terrible as the tool never captured things like mouseover or hover events
that were needed to bring an objects into the state where you could see it
or interact with it. (maybe it's better now? it's been years since I used
a recorder)
On Tuesday, April 2, 2013 2:12:46 AM UTC-7, Željko Filipin wrote:
>
> On Sat, Mar 30, 2013 at 2:33 AM, Ekin Han <[email protected] <javascript:>
> > wrote:
>
>> Does selenium ide support watir webdriver formmater, or is that possible
>> to write a formatter for watir webdriver using selenium IDE api?
>
>
> You will get better support at selenium ide mailing list, if it exists.
> Selenium ide is not part of watir project. You will notice that watir
> people do not like recorders at all.
>
> Željko
> --
> https://leanpub.com/watirbook
>
--
--
Before posting, please read http://watir.com/support. In short: search before
you ask, be nice.
[email protected]
http://groups.google.com/group/watir-general
[email protected]
---
You received this message because you are subscribed to the Google Groups
"Watir General" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
