With regard to my rant below, I just ran across this great example in a
stack overflow question. I strongly suspect this is someone who learned to
automate using a recorder.. this is the kind of crap a that recorder
'teaches' people to code. (those sensitive to unreadable code should look
away now)
browser.element(:xpath,
'/html/body/div[5]/div[2]/div/div/div/div[2]/div/div/div/div/div/div/div/div[2]/div/div[2]/div/div/table/tbody[2]/tr[1]/td[1]/div').double_click
nuff said?
On Wednesday, April 3, 2013 10:05:30 AM UTC-7, Chuck van der Linden wrote:
>
> 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]> 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.
