I completely agree, WATIR does it's extraordinary performance in the case of stale element reference error, the only reason is because it continue to invoke the find_element until it finds the element and I know that's the reason WATIR avoids implicit wait. That's excellent. But you are not caring certain places which falls into the infinite loop which I explained earlier, For an example,
Consider this following code def set(*args) element_call(:wait_for_writable) do @element.clear @element.send_keys(*args) end end What my application does is, it refreshes the page after the clearing the element, So after @element.clear,( since page got refreshed), @element object is stale now, So @element.send_keys throws the error but it's been caught by the given block below begin send exist_check yield rescue Selenium::WebDriver::Error::StaleElementReferenceError retry ensure Wait.timer.reset! unless already_locked end So it is retrying, but what happens is, once again it starts from the beginning, So when it executes @element.clear, it once again goes to stale state, So it falls into the infinite loop and it never comes out. So what you would have done here is, you could have written the code like given below def set(*args) element_call(:wait_for_writable) do @element.send_keys([:control,"a"],*args) end end Now the problem solved because choosing the entire cell content and then writing on it automatically does the clearing Job. So the element doesn't go stale in this case. On Friday, March 24, 2017 at 12:25:36 PM UTC-7, Titus Fortner wrote: > > Yes, Watir is slower. Think of Selenium as a "Do What I Say" tool. If you > can enumerate exactly what you need using its low level commands then you > can be very performant. Watir is a "Do What I Mean" tool. Watir's goal is > not speed, but ease of writing, ease of maintenance, consistency of > results, and usefulness of error messages for debugging. > > There are many advantages to using Watir over Selenium directly which I > need to spend time enumerating in a blog post at some point, but the two > most important things that Watir does right now is automatically handle > Stale Element Reference errors (the bane of many test automation suites), > and automatically wait for the site's condition to be synchronized with > what is expected of the test based on the Watir code. There are many other > conveniences that may not always be needed but are provided by default so > that no user has to do extra work to handle it when it is necessary. > > Watir can slow things down a little or a lot depending on what you are > trying to do. I have some ideas to increase performance in some situations, > but again, my focus is primarily on making it easy for people who don't > know all the details of their website's implementation to get consistent > results. > > Titus > > > On Thursday, March 23, 2017 at 12:16:00 PM UTC-5, Raja gopalan wrote: >> >> Titus, I stongly believe checking enabled? present? writable? methods are >> unnecessary calls by WATIR because we know what kind of field we are going >> to interact so these calls to every element slows down the process So what >> I did was, I have CALLED the driver out of WATIR and started writing >> selenium code and wherever I want the help of WATIR help like >> b.table.rows.each, I will write watir code and also If I know there are >> certain element starts to appear after the click then I write watir code, >> So I am mixing the selenium code and WATIR code as shown below, >> >> For an example, look at the code below and see how I have mixed the >> selenium code and WATIR CODE >> >> require 'watir' >> >> class Cable >> >> def initialize >> caps = Selenium::WebDriver::Remote::Capabilities.firefox(marionette: >> false) >> @b=Watir::Browser.new :firefox, desired_capabilities: caps >> @b.goto 'smcnet.in/' >> @driver=@b.driver >> end >> >> def call >> @driver.find_element(:id, 'username').send_keys 'raja' >> @driver.find_element(:id, 'password').send_keys '' >> @driver.find_element(:xpath, "//*[@value='Log In']").click >> @driver.find_element(link: 'My Plan').click >> @b.element(xpath: "//span[normalize-space(.)='usage details']").click >> # WATIR CODE >> puts @b.div(:text, 'MB Used').following_sibling.span.text >> # WATIR CODE >> puts @b.div(:text, 'Days Remaining').following_sibling.span.text >> # WATIR CODE >> @driver.find_element(link: 'Hi, RAJAGOPALAN M').click >> @driver.find_element(:xpath, '//li[3]/a').click >> # @driver.quit >> end >> end >> >> >> On Thursday, March 23, 2017 at 10:06:26 AM UTC-7, Titus Fortner wrote: >>> >>> Yes, #present? is a combination of #exists? and #visible? >>> >>> Also, with Watir 6, you are less likely to need to make this call >>> explicitly in the code. Taking actions on an element will automatically >>> wait for element to be present if necessary. >>> >> -- -- Before posting, please read http://watir.com/support. 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.
