[wtr-general] How often to get element reference, best practice?

Discussion:

NaviHan

2018-09-11 04:52:32 UTC

This is something that keeps me a bit sceptic when I write and read the
automation code in my project.
This used PageObjects.

I have seen extensive use of element referces, for example

button(:add_to_bag, :css => '#add-to-cart')
add_to_bag.element.when_present.click

instead of

add_to_bag

which directly clicks the element

I have also seen extensive use of referencing elements using <element>.when_present, <element>.wait_until_present etc

Im confused where we should draw the line when deciding to reference the element and actually using it(as in directly calling "add_o_bag" in the above example to click the element.

Any thoughts?
--
--
Before posting, please read https://github.com/watir/watir_meta/wiki/Guidelines-for-Posting-to-Watir-General-Google-Group.
In short: search before you ask, be nice.

watir-***@googlegroups.com
http://groups.google.com/group/watir-general
watir-general+***@googlegroups.com
---
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 watir-general+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Justin Ko

2018-09-11 13:40:28 UTC

Permalink

In that example, you should just #add_to_bag.

I'm guessing that you are working with a code base that is older than Watir
6.0. Before v6.0, add_to_bag_element.when_present.click was required for
elements that were not immediately present on page load (ie you needed to
wait for them to appear). In Watir 6.0, Titus made changes to automatically
wait for elements before taking actions. As a result, pre-6.0
add_to_bag_element.when_present.click would be equivalent to v6.0
add_to_bag_element.click. add_to_bag_element.click is equivalent to the
accessor created add_to_bag.

In general, I would say:
- You do not need the waits when taking actions (eg click, inputting, etc)
on an element.
- Use the page object accessor's methods if available (ie don't duplicate
the framework)

Justin

Post by NaviHan
This is something that keeps me a bit sceptic when I write and read the
automation code in my project.
This used PageObjects.
I have seen extensive use of element referces, for example
button(:add_to_bag, :css => '#add-to-cart')
add_to_bag.element.when_present.click
instead of
add_to_bag
which directly clicks the element
I have also seen extensive use of referencing elements using <element>.when_present, <element>.wait_until_present etc
Im confused where we should draw the line when deciding to reference the element and actually using it(as in directly calling "add_o_bag" in the above example to click the element.
Any thoughts?

--
--
Before posting, please read https://github.com/watir/watir_meta/wiki/Guidelines-for-Posting-to-Watir-General-Google-Group.
In short: search before you ask, be nice.

watir-***@googlegroups.com
http://groups.google.com/group/watir-general
watir-general+***@googlegroups.com
---
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 watir-general+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

NaviHan

2018-09-11 13:50:05 UTC

Permalink

Hi Justin

Unfortunately thats not the truth. We started automation for our project
approximately an year back, and Im pretty sure the version since the start
is post 6.0.
We are doing these kind of duplication out of ignorance.

Coming to the question, does watir show any warnings if we use
"add_to_bag_element.when_present.click" instead of "add_to_bag"?

And is the wait the default of 30 seconds?

Can you give an example where we have to explicitly wait?

Cheers

Justin Ko

2018-09-11 15:39:32 UTC

Permalink

Hi Navi,

(This is just response to your first reply. I'll have a look at your other
replies when I have more time.)

`add_to_bag_element.when_present.click` would be Page-Object code rather
than Watir code. There are no warnings that would be thrown from it.

Switching to `add_to_bag` will increase the timeout from 5 to 30 seconds
(assuming you haven't overridden the defaults):
- Page Object's `#when_present` only waits 5 seconds
- Watir's `#click` waits 30 seconds

You should only need to wait when inspecting the element (rather than
taking a user action). For example, checking the element's text waits for
the element to exist, but not for it to be present. Keep in mind that you
would only need to wait if the thing you are inspecting would change based
on being hidden or not. #text can matter since it only shows visible text
nodes. Checking most attributes, ex #id, presumably wouldn't matter. In
general, the hope of Watir 6.0 is that you would rarely need to add the
waits.

Justin

Post by NaviHan
Hi Justin
Unfortunately thats not the truth. We started automation for our project
approximately an year back, and Im pretty sure the version since the start
is post 6.0.
We are doing these kind of duplication out of ignorance.
Coming to the question, does watir show any warnings if we use
"add_to_bag_element.when_present.click" instead of "add_to_bag"?
And is the wait the default of 30 seconds?
Can you give an example where we have to explicitly wait?
Cheers

NaviHan

2018-09-11 14:40:29 UTC

Permalink

Hi Justin/Titus

I have read the watit 6.0 release notes and FAQ
@ http://watir.com/watir-6-faq/#H
Thanks a lot for giving the valuable info.

Until now I was under the impression that "element.when_present" &
"element.wait_until(&:present)", but reading the notes I understood that
they are different.

Arent both waiting for deafult of "30" seconds for the element to be
present? What is the difference between the two?

Titus Fortner

2018-09-11 16:10:14 UTC

Permalink

Oh man, that FAQ is kind of dated, and more confusing than I remember it
being. I should tidy a couple things there.

The specific use case detailed in "Why are my tests taking so long?"
section of that FAQ is going to be rare, and very unlikely to apply to you.
So you should just ignore that one. :)

when_present - Waits for element to be present, now deprecated

wait_until(&:present?) - Waits for element to be present; this is
recommended usage.

wait_until_present - this one is slightly trickier, and hopefully the need
for it goes away in a future release. Essentially this method is needed in
a very rare use case: the element is located, then goes away, and you want
to wait for it to come
back. http://watir.com/guides/waiting/#wait-until-present-and-wait-while-present

relaxed_locate = true is the default. Relaxed means that it will
automatically wait for elements to be present if they are not.
relaxed_locate = false is for people who want to use Watir 6, but do not
want the automatic waiting behaviors. (these are the people who had issues
with the "Why are my tests taking so long?" section of the FAQ)

Watir 7 will be deprecating this setting entirely, and relaxed_locate will
be true for everyone.

Post by NaviHan
Hi Justin/Titus
http://watir.com/watir-6-faq/#H
Thanks a lot for giving the valuable info.
Until now I was under the impression that "element.when_present" &
"element.wait_until(&:present)", but reading the notes I understood that
they are different.
Arent both waiting for deafult of "30" seconds for the element to be
present? What is the difference between the two?

NaviHan

2018-09-11 14:59:25 UTC

Permalink

Sorry to too many replies. But this is really killing me. I see there is
anothet wait which is wait_until_present?

Someone please clarify the difference between the 3

1. element.when_present, which is deprecated and auto included from watir
6.0 onwards
2. element.wait_until(&:present) which is same as element.wait_until {|el
el.present?)|} &
3. element.wait_until_present

I have read that two is used when Watir.relaxed_locate = false two but why
would someone ever set this to true? which means watir doesnt wait for an
element to be found or present before taking an action.

Thanks

NaviHan

2018-09-12 04:49:36 UTC

Permalink

Hi Titus

You said "when_present" and 'wait_until(&:present?)" does the same thing,
which is Waits for element to be present, the former is deprecated and
latter is recommended.

Why is that if bot does the same thing

Im trying to understand if "wait_until(&:present?)" is in any ways
different from "when_present" eventhough its deprecated.

Justin also mentioned on version 6.0 of Watir you made changes to
automatically wait for elements before taking actions which let us do away
ith "when_present". So I still do not understand why we should ever use
wait_until(&:present?) at all.

Sorry if I sound stupid, becasue there is so much cinfusion around waits :-(

Cheers
Navi

Titus Fortner

2018-09-12 15:25:27 UTC

Permalink

Hey Navi, I'm sorry there is so much confusion around the waits. If there
is something that would make this article
(http://watir.com/guides/waiting/) more clear, please let me know so I can
make it better. Maybe I spend too much time focusing on history and
implementation details that don't matter to you?

Best practice before Watir 6:

Scenario one, click element that eventually displays:
my_element.when_present.click

Scenario two, get info from element that eventually displays:
my_element.when_present.get_attribute('class')

Secnario three, wait for one element then act on another:
my_element1.wait_until_present
my_element2.click

For the first scenario,
since your test shouldn't attempt to click an element that isn't present,
Watir 6 made the waiting automatic.

This will now do the exact same thing:
my_element.click

Scenario 2:
Watir waits for the element to exist, but not for it to be displayed. So if
it needs to be displayed first (usually some kind of dynamic activity on
the page):

element.wait_until(&:present?).attribute_value('class')

Scenario 3:

element_one.wait_until(&:present?)
element_two.click

We are encouraging everyone to move to the to_proc notation `&:` with the
wait methods. This drastically simplifies the code we have to maintain
relative to the benefit to our users. We do still have
`#wait_until_present` and `#wait_while_present` methods to handle some
special use cases, but these may go away as well.

Does this clarify things more?

Post by NaviHan
Hi Titus
You said "when_present" and 'wait_until(&:present?)" does the same thing,
which is Waits for element to be present, the former is deprecated and
latter is recommended.
Why is that if bot does the same thing
Im trying to understand if "wait_until(&:present?)" is in any ways
different from "when_present" eventhough its deprecated.
Justin also mentioned on version 6.0 of Watir you made changes to
automatically wait for elements before taking actions which let us do away
ith "when_present". So I still do not understand why we should ever use
wait_until(&:present?) at all.
Sorry if I sound stupid, becasue there is so much cinfusion around waits :-(
Cheers
Navi

NaviHan

2018-09-13 03:19:11 UTC

Permalink

Hi Titus

Thanks for the detailed explanation and the documentation link.
Unfortunately my confusion doesnt get clarified.

As you said for an element which eventually displays, for example a pop up
that appears due to a user action, we can read the text by

*scenario 1*
"my_element.when_present.text" because when_present get info from element
that eventually *displays*

The above changed to my_element.text, post Watir6.0 as the wait was made
automatic

*scenario 2*
"my_element.wait_until(&:present?).text" also waits for the element to be
displayed like "my_element.when_present.text"
So they are one and the same.

Because they are one and the same and post Watir6.0 the when_present wait
was made automatic we can achieve the above objective with "my_element.text"

So there will never be a case where we have to use wait_until(&:present?).

This is my theory.
Is that correct?

Cheers
Navi

Titus Fortner

2018-09-13 05:21:24 UTC

Permalink

Yeah, it is automatic only for action methods, which does not include text.
There's a case to be made to extend that behavior to text since it will
return an empty string if it isn't displayed, but for now you'll need to
keep the wait.

Post by NaviHan
Hi Titus
Thanks for the detailed explanation and the documentation link.
Unfortunately my confusion doesnt get clarified.
As you said for an element which eventually displays, for example a pop up
that appears due to a user action, we can read the text by
*scenario 1*
"my_element.when_present.text" because when_present get info from element
that eventually *displays*
The above changed to my_element.text, post Watir6.0 as the wait was made
automatic
*scenario 2*
"my_element.wait_until(&:present?).text" also waits for the element to be
displayed like "my_element.when_present.text"
So they are one and the same.
Because they are one and the same and post Watir6.0 the when_present wait
was made automatic we can achieve the above objective with "my_element.text"
So there will never be a case where we have to use wait_until(&:present?).
This is my theory.
Is that correct?
Cheers
Navi

--
Before posting, please read
https://github.com/watir/watir_meta/wiki/Guidelines-for-Posting-to-Watir-General-Google-Group.
In short: search before you ask, be nice.
http://groups.google.com/group/watir-general
---
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
For more options, visit https://groups.google.com/d/optout.

NaviHan

2018-09-13 05:46:26 UTC

Permalink

Hi Titus

Thats makes it very clear now :-)

Just to confirm, action methods as in set, click, select
And the reading attribute values like id, text, or any other custom
attribute are not auto covered and we need to use wait_until(&:present?)

Is that correct?

Cheers
Navi

rajagopalan madasami

2018-09-13 11:40:37 UTC

Permalink

Hi Navi,

yes, you are right with your understanding.

WATIR locates elements completely different from Selenium

When you write,

element=b.span(id: 'click')

It doesn't locate the element, but when you write

element.click

it locates the element and continue to perform the click operation, this
arrangement is useful to relocate the element when element goes to stale,
waiting until element is visible and likewise this arrangement is useful
for cases. Technically this should include even when I call text method as
well. But I do in my project here is,

I write code like

b.wait_until(b.label(id: 'something').text?'Expected Text')

This will reexecute the statement for 30 seconds, otherwise it would throw
the error

Or

b.label(id: 'something').wait_until{|element| element.text.eql?'Expected
Text'}

Post by NaviHan
Hi Titus
Thats makes it very clear now :-)
Just to confirm, action methods as in set, click, select
And the reading attribute values like id, text, or any other custom
attribute are not auto covered and we need to use wait_until(&:present?)
Is that correct?
Cheers
Navi

Titus Fortner

2018-09-13 15:29:58 UTC

Permalink

As of 6.13 you can now that wait like this:

b.label(id: 'something').wait_until(text: 'Expected Text')

On Thursday, September 13, 2018 at 4:40:53 AM UTC-7, rajagopalan madasami

Post by Justin Ko
Hi Navi,
yes, you are right with your understanding.
WATIR locates elements completely different from Selenium
When you write,
element=b.span(id: 'click')
It doesn't locate the element, but when you write
element.click
it locates the element and continue to perform the click operation, this
arrangement is useful to relocate the element when element goes to stale,
waiting until element is visible and likewise this arrangement is useful
for cases. Technically this should include even when I call text method as
well. But I do in my project here is,
I write code like
b.wait_until(b.label(id: 'something').text?'Expected Text')
This will reexecute the statement for 30 seconds, otherwise it would throw
the error
Or
b.label(id: 'something').wait_until{|element| element.text.eql?'Expected
Text'}

rajagopalan madasami

2018-09-13 16:57:21 UTC

Permalink

Yes, I saw this new change in your new article but I can't use WATIR 6.13
because as you know, its not waiting for select list.

Post by Titus Fortner
b.label(id: 'something').wait_until(text: 'Expected Text')
On Thursday, September 13, 2018 at 4:40:53 AM UTC-7, rajagopalan madasami

Post by Justin Ko
Hi Navi,
yes, you are right with your understanding.
WATIR locates elements completely different from Selenium
When you write,
element=b.span(id: 'click')
It doesn't locate the element, but when you write
element.click
it locates the element and continue to perform the click operation, this
arrangement is useful to relocate the element when element goes to stale,
waiting until element is visible and likewise this arrangement is useful
for cases. Technically this should include even when I call text method as
well. But I do in my project here is,
I write code like
b.wait_until(b.label(id: 'something').text?'Expected Text')
This will reexecute the statement for 30 seconds, otherwise it would
throw the error
Or
b.label(id: 'something').wait_until{|element| element.text.eql?'Expected
Text'}

--
Before posting, please read
https://github.com/watir/watir_meta/wiki/Guidelines-for-Posting-to-Watir-General-Google-Group.
In short: search before you ask, be nice.
http://groups.google.com/group/watir-general
---
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
For more options, visit https://groups.google.com/d/optout.

Titus Fortner

2018-09-14 01:48:30 UTC

Permalink

6.14 was just released, hopefully it addresses your issues.
On Thu, Sep 13, 2018 at 9:57 AM rajagopalan madasami

Yes, I saw this new change in your new article but I can't use WATIR 6.13 because as you know, its not waiting for select list.

Post by Titus Fortner
b.label(id: 'something').wait_until(text: 'Expected Text')

Post by Justin Ko
Hi Navi,
yes, you are right with your understanding.
WATIR locates elements completely different from Selenium
When you write,
element=b.span(id: 'click')
It doesn't locate the element, but when you write
element.click
it locates the element and continue to perform the click operation, this arrangement is useful to relocate the element when element goes to stale, waiting until element is visible and likewise this arrangement is useful for cases. Technically this should include even when I call text method as well. But I do in my project here is,
I write code like
b.wait_until(b.label(id: 'something').text?'Expected Text')
This will reexecute the statement for 30 seconds, otherwise it would throw the error
Or
b.label(id: 'something').wait_until{|element| element.text.eql?'Expected Text'}

Post by NaviHan
Hi Titus
Thats makes it very clear now :-)
Just to confirm, action methods as in set, click, select
And the reading attribute values like id, text, or any other custom attribute are not auto covered and we need to use wait_until(&:present?)
Is that correct?
Cheers
Navi

--
--
Before posting, please read https://github.com/watir/watir_meta/wiki/Guidelines-for-Posting-to-Watir-General-Google-Group.
In short: search before you ask, be nice.
http://groups.google.com/group/watir-general
---
You received this message because you are subscribed to the Google Groups "Watir General" group.
For more options, visit https://groups.google.com/d/optout.

rajagopalan madasami

2018-09-14 03:41:09 UTC

Permalink

Waiting for select list is added?

Post by Titus Fortner
6.14 was just released, hopefully it addresses your issues.
On Thu, Sep 13, 2018 at 9:57 AM rajagopalan madasami

Post by rajagopalan madasami
Yes, I saw this new change in your new article but I can't use WATIR

6.13 because as you know, its not waiting for select list.