[wtr-general] Re: How often to get element reference, best practice?
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 On Tuesday, 11 September 2018 14:52:33 UTC+10, NaviHan wrote: > > 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 > .when_present, .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-general@googlegroups.com http://groups.google.com/group/watir-general watir-general+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [wtr-general] Re: Watir [DEPRECATION] ["stale_present"] Checking `#present? == false`
Good news. I figured out how to minimize this message. Everything should be better in 6.14. :) On Tuesday, September 11, 2018 at 8:54:49 AM UTC-7, Titus Fortner wrote: > > The deprecation message is thrown when rescuing a stale exception during a > call for #exists? / #visible? #present? because when we make the code > changes below, tests that rely on this behavior will fail. They need to > know about it, so there needs to be a message. Yes, the message is > happening even in use cases that won't change, so I'll need to adjust the > message. > > As for the specific code I suggested, you wouldn't be getting a stale > element warning if the element was in the DOM and merely not displayed. As > such `wait_while(&:exists?)` would do what you need it to do just fine. > Alternately, the method `#wait_while_present` should work as well since it > is constantly locating from scratch. Yes, this is just for the element > going away. To deal with the element showing up and then going away is a > completely separate concern. > > Also, for note, specific requests for changing code are better done as > github issues so I can keep track of them. > > > > > > > On Tuesday, September 11, 2018 at 5:04:45 AM UTC-7, rajagopal...@gmail.com > wrote: >> >> element.wait_while(&:exists?) >> >> >> No, this wouldn't work, I have to wait until the element is visible, >> element becomes invisible when loading completes. >> >> And also, I am checking whether element is visible or not, I am checking >> whether previously located element exist in the DOM. So this line >> b.div().wait_until_present or b.div.wait_until(&:present) perfectly needed >> for my program. >> >> I am well aware of how element is located in selenium and WATIR. but I >> don't understand the deprecation message has to be thrown such a meaningful >> method. Please remove this message completely. >> >> Thanks. >> >> On Thursday, September 6, 2018 at 7:14:13 AM UTC+5:30, Titus Fortner >> wrote: >>> >>> This is another example of the deprecation notice being thrown more >>> often than it should be. I've verified that your code will work after my >>> planned deprecation. I can't figure out how to restrict this deprecation >>> notice, so I'll add something to the message. >>> >>> Right now, to avoid that notice, you can do: element.wait_while(& >>> :exists?) >>> >>> Watir and Selenium have fundamentally different ideas of what an element >>> "is." A Selenium Element is defined by the object reference returned by the >>> driver. If that reference is no longer valid, the element no longer exists. >>> A Watir Element is whatever exists is at the provided locator, period. The >>> Watir approach is more useful if you are focused on testing functionality >>> vs implementation. When watir-webdriver was created, a lot of Selenium >>> implementation ideas creeped into Watir. This refactoring is make the >>> distinction more consistent with the original intentions of Watir. >>> >>> If a Watir user cares about the Selenium notion of what an element is, >>> we've provided the `#stale?` method to allow you to figure out if the >>> driver object has gone away. Additionally, for performance reasons Watir >>> caches the Selenium element and tries to re-use it whenever possible. which >>> adds a bit of extra complexity. >>> >>> If you're curious, the refactoring is going to change #exists? from this: >>> >>> def exists? >>> return false if located? && stale? >>> assert_exists >>> true >>> rescue UnknownObjectException, UnknownFrameException >>> false >>> end >>> >>> >>> to this: >>> >>> def exists? >>> if located? && stale? >>> reset! >>> elsif located? >>> return true >>> end >>> >>> assert_exists >>> true >>> rescue UnknownObjectException, UnknownFrameException >>> false >>> end >>> >>> >>> and `#present?` will look like: >>> >>> def present? >>> begin >>> assert_exists >>> @element.displayed? >>> rescue Selenium::WebDriver::Error::StaleElementReferenceError >>> reset! >>> retry # (this was changed from just returning false) >>> rescue UnknownObjectException, UnknownFrameException >>> false >>> end >>> end >>> >>> >>> >>> >>> >>> On Wednesday, September 5, 2018 at 9:31:12 AM UTC-7, rajagopalan >>> madasami wrote: Yes I am asking the former, I need to wait until spinner goes away. So former one is necessary for me. Buy why do you plan to deprecate such a good method which is very much necessary? On Wed 5 Sep, 2018, 8:06 PM Titus Fortner, wrote: > It has to do with how Watir caches elements and being consistent in > how it responds. > > "#present?" is asking "can a user see an element at this location?" > This is different from "did the element I previously located change?" > > If you are asking the former, you're fine. If you are asking the > latter, you might need to change your code. > I can take another pass at
[wtr-general] Re: How often to get element reference, best practice?
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. On Tuesday, September 11, 2018 at 7:40:29 AM UTC-7, NaviHan wrote: > > 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? > > On Tuesday, 11 September 2018 14:52:33 UTC+10, NaviHan wrote: >> >> 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 >> .when_present, .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-general@googlegroups.com http://groups.google.com/group/watir-general watir-general+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [wtr-general] Re: Watir [DEPRECATION] ["stale_present"] Checking `#present? == false`
The deprecation message is thrown when rescuing a stale exception during a call for #exists? / #visible? #present? because when we make the code changes below, tests that rely on this behavior will fail. They need to know about it, so there needs to be a message. Yes, the message is happening even in use cases that won't change, so I'll need to adjust the message. As for the specific code I suggested, you wouldn't be getting a stale element warning if the element was in the DOM and merely not displayed. As such `wait_while(&:exists?)` would do what you need it to do just fine. Alternately, the method `#wait_while_present` should work as well since it is constantly locating from scratch. Yes, this is just for the element going away. To deal with the element showing up and then going away is a completely separate concern. Also, for note, specific requests for changing code are better done as github issues so I can keep track of them. On Tuesday, September 11, 2018 at 5:04:45 AM UTC-7, rajagopal...@gmail.com wrote: > > element.wait_while(&:exists?) > > > No, this wouldn't work, I have to wait until the element is visible, > element becomes invisible when loading completes. > > And also, I am checking whether element is visible or not, I am checking > whether previously located element exist in the DOM. So this line > b.div().wait_until_present or b.div.wait_until(&:present) perfectly needed > for my program. > > I am well aware of how element is located in selenium and WATIR. but I > don't understand the deprecation message has to be thrown such a meaningful > method. Please remove this message completely. > > Thanks. > > On Thursday, September 6, 2018 at 7:14:13 AM UTC+5:30, Titus Fortner wrote: >> >> This is another example of the deprecation notice being thrown more often >> than it should be. I've verified that your code will work after my planned >> deprecation. I can't figure out how to restrict this deprecation notice, so >> I'll add something to the message. >> >> Right now, to avoid that notice, you can do: element.wait_while(&:exists? >> ) >> >> Watir and Selenium have fundamentally different ideas of what an element >> "is." A Selenium Element is defined by the object reference returned by the >> driver. If that reference is no longer valid, the element no longer exists. >> A Watir Element is whatever exists is at the provided locator, period. The >> Watir approach is more useful if you are focused on testing functionality >> vs implementation. When watir-webdriver was created, a lot of Selenium >> implementation ideas creeped into Watir. This refactoring is make the >> distinction more consistent with the original intentions of Watir. >> >> If a Watir user cares about the Selenium notion of what an element is, >> we've provided the `#stale?` method to allow you to figure out if the >> driver object has gone away. Additionally, for performance reasons Watir >> caches the Selenium element and tries to re-use it whenever possible. which >> adds a bit of extra complexity. >> >> If you're curious, the refactoring is going to change #exists? from this: >> >> def exists? >> return false if located? && stale? >> assert_exists >> true >> rescue UnknownObjectException, UnknownFrameException >> false >> end >> >> >> to this: >> >> def exists? >> if located? && stale? >> reset! >> elsif located? >> return true >> end >> >> assert_exists >> true >> rescue UnknownObjectException, UnknownFrameException >> false >> end >> >> >> and `#present?` will look like: >> >> def present? >> begin >> assert_exists >> @element.displayed? >> rescue Selenium::WebDriver::Error::StaleElementReferenceError >> reset! >> retry # (this was changed from just returning false) >> rescue UnknownObjectException, UnknownFrameException >> false >> end >> end >> >> >> >> >> >> On Wednesday, September 5, 2018 at 9:31:12 AM UTC-7, rajagopalan madasami >> wrote: >>> >>> Yes I am asking the former, I need to wait until spinner goes away. So >>> former one is necessary for me. Buy why do you plan to deprecate such a >>> good method which is very much necessary? >>> >>> On Wed 5 Sep, 2018, 8:06 PM Titus Fortner, wrote: >>> It has to do with how Watir caches elements and being consistent in how it responds. "#present?" is asking "can a user see an element at this location?" This is different from "did the element I previously located change?" If you are asking the former, you're fine. If you are asking the latter, you might need to change your code. I can take another pass at making sure the warning is sufficiently narrow. On Wednesday, September 5, 2018 at 12:01:15 AM UTC-7, rajagopal...@gmail.com wrote: > > Hi Titus, > > I am getting this warning while I execute this code > >> >> @b.span(class: "spinner").wait_while(&:present?) >>
[wtr-general] Re: How often to get element reference, best practice?
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
On Tuesday, 11 September 2018 14:52:33 UTC+10, NaviHan wrote:
>
> 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
> .when_present, .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-general@googlegroups.com
http://groups.google.com/group/watir-general
watir-general+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[wtr-general] Re: How often to get element reference, best practice?
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? On Tuesday, 11 September 2018 14:52:33 UTC+10, NaviHan wrote: > > 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 > .when_present, .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-general@googlegroups.com http://groups.google.com/group/watir-general watir-general+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[wtr-general] Re: How often to get element reference, best practice?
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 On Tuesday, 11 September 2018 14:52:33 UTC+10, NaviHan wrote: > > 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 > .when_present, .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-general@googlegroups.com http://groups.google.com/group/watir-general watir-general+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[wtr-general] Re: How often to get element reference, best practice?
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 On Tuesday, September 11, 2018 at 12:52:33 AM UTC-4, NaviHan wrote: > > 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 > .when_present, .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-general@googlegroups.com http://groups.google.com/group/watir-general watir-general+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [wtr-general] Re: Watir [DEPRECATION] ["stale_present"] Checking `#present? == false`
> > element.wait_while(&:exists?) No, this wouldn't work, I have to wait until the element is visible, element becomes invisible when loading completes. And also, I am checking whether element is visible or not, I am checking whether previously located element exist in the DOM. So this line b.div().wait_until_present or b.div.wait_until(&:present) perfectly needed for my program. I am well aware of how element is located in selenium and WATIR. but I don't understand the deprecation message has to be thrown such a meaningful method. Please remove this message completely. Thanks. On Thursday, September 6, 2018 at 7:14:13 AM UTC+5:30, Titus Fortner wrote: > > This is another example of the deprecation notice being thrown more often > than it should be. I've verified that your code will work after my planned > deprecation. I can't figure out how to restrict this deprecation notice, so > I'll add something to the message. > > Right now, to avoid that notice, you can do: element.wait_while(&:exists?) > > Watir and Selenium have fundamentally different ideas of what an element > "is." A Selenium Element is defined by the object reference returned by the > driver. If that reference is no longer valid, the element no longer exists. > A Watir Element is whatever exists is at the provided locator, period. The > Watir approach is more useful if you are focused on testing functionality > vs implementation. When watir-webdriver was created, a lot of Selenium > implementation ideas creeped into Watir. This refactoring is make the > distinction more consistent with the original intentions of Watir. > > If a Watir user cares about the Selenium notion of what an element is, > we've provided the `#stale?` method to allow you to figure out if the > driver object has gone away. Additionally, for performance reasons Watir > caches the Selenium element and tries to re-use it whenever possible. which > adds a bit of extra complexity. > > If you're curious, the refactoring is going to change #exists? from this: > > def exists? > return false if located? && stale? > assert_exists > true > rescue UnknownObjectException, UnknownFrameException > false > end > > > to this: > > def exists? > if located? && stale? > reset! > elsif located? > return true > end > > assert_exists > true > rescue UnknownObjectException, UnknownFrameException > false > end > > > and `#present?` will look like: > > def present? > begin > assert_exists > @element.displayed? > rescue Selenium::WebDriver::Error::StaleElementReferenceError > reset! > retry # (this was changed from just returning false) > rescue UnknownObjectException, UnknownFrameException > false > end > end > > > > > > On Wednesday, September 5, 2018 at 9:31:12 AM UTC-7, rajagopalan madasami > wrote: >> >> Yes I am asking the former, I need to wait until spinner goes away. So >> former one is necessary for me. Buy why do you plan to deprecate such a >> good method which is very much necessary? >> >> On Wed 5 Sep, 2018, 8:06 PM Titus Fortner, wrote: >> >>> It has to do with how Watir caches elements and being consistent in how >>> it responds. >>> >>> "#present?" is asking "can a user see an element at this location?" >>> This is different from "did the element I previously located change?" >>> >>> If you are asking the former, you're fine. If you are asking the latter, >>> you might need to change your code. >>> I can take another pass at making sure the warning is sufficiently >>> narrow. >>> >>> >>> >>> On Wednesday, September 5, 2018 at 12:01:15 AM UTC-7, >>> rajagopal...@gmail.com wrote: Hi Titus, I am getting this warning while I execute this code > > @b.span(class: "spinner").wait_while(&:present?) > > 2018-09-05 12:26:45 WARN Watir [DEPRECATION] ["stale_present"] Checking `#present? == false` to determine a stale element is deprecated. Use `#stale? == true` instead. If I use @b.span(class: "spinner").wait_until(&:stale?) > > Watir::Exception::Error: Can not check staleness of unused element 0) scenario1-Contact Example ?[31mFailure/Error: raise Watir::Exception::Error, "Can not check staleness of unused element" unless @element?[0m ?[31m?[0m ?[31mWatir::Exception::Error:?[0m ?[31m Can not check staleness of unused element?[0m ?[36m# ./Source/FrameWorkModules/Chrome.rb:168:in `waitForPageLoad'?[0m ?[36m# ./Source/LoginModule/login.rb:72:in `driverSing'?[0m ?[36m# ./Source/FrameWorkModules/PullTheTestCases.rb:7:in `initialize'?[0m ?[36m# ./Source/Contact_Create_spec.rb:36:in `new'?[0m ?[36m# ./Source/Contact_Create_spec.rb:36:in `block (4 levels) in '?[0m Why can't I use `@b.span(class: "spinner").wait_while(&:present?)` ? Hi, I am designing a common framework for
