watir-webdriver 的等待方法在 JS/AJAX 和新页面加载中失败(缓存中未找到错误)
我正在测试一个基于 Magento 店面构建的内部网站。在结账过程中,表格的某些部分会被隐藏(样式:无),直到填写完上一部分为止。这些部分通常会破坏脚本,但使用when_present作为隐藏表单的第一个元素解决了这个问题。
然而,“提交订单”按钮不能很好地使用这些相同的方法。今天我与我们的首席开发人员合作,验证此按钮与之前的表单按钮之间的唯一区别是加载了新页面(新 URL、浏览器中新的“完成”状态)。
为了一目了然:
- 用户输入姓名、地址、电子邮件并单击“继续”=> JS“加载”动画旋转,同时“常规”面板滑动关闭,“运输方式”面板展开,所有这些都在同一页面上。
- 用户点击“提交订单”=> JS“加载”动画旋转,完成后,浏览器将进入 /success/ (新页面)并包含可验证的元素。
- 如果有足够的时间来完成(睡眠语句),测试就会通过。
以下是表单的伪代码,然后单击“提交”:
def complete_form(data = {})
data = DEFAULT_DATA.merge (data)
select_guest
continue_button.click #proceed to billing panel
enter_billing_and_shipping_info(data)
enter_additional_information(data)
place_order_button.when_present.click #submit form
#sleep 2 #this succeeds, but is undesirable
thank_you_message.wait_until_present #I do not actually appear to wait until anything is present
end #
def enter_billing_and_shipping_info(data)
billing_first_name.when_present.value = data['First Name'] #I work!
billing_last_name.value = data['Last Name']
#more fields
end #
从步骤:
thank_you_message.should include("Yippee")
脚本以两种不同的方式失败,具体取决于站点响应的速度:
- 失败,并显示未找到预期感谢消息的消息 - a错误期间截取的屏幕截图显示结账页面,而不是感谢页面,并显示“正在加载”动画。 (预期“结账”包含“您的订单已收到”)
- 失败,并出现“缓存中未找到元素”错误 - 本例中的屏幕截图确实显示了“谢谢”页面,其中包含我们正在寻找的文本
其他方法,例如如 Watir::Wait.until 或直到 {} 所做的那样,会导致相同的行为。
- Windows 7 64 位和 Windows 7 Windows XP 32 位
- ruby 1.9.2p290 (2011-07-09) [i386-mingw32]
- cucumber (1.0.2)
- rspec ( 1.3.2)
- watir-webdriver (0.3.0)
更新 8-15 尝试的解决方案#1:
place_order_button.when_present.click #complete form
ajax_submit_image.wait_while_present
相同的最终结果 - 脚本终止,未找到成功消息,屏幕截图显示 Ajax 加载图像中旋转。这个方法和前面的方法都应该有效,但似乎没有效果。我确实验证了我可以使用脚本中的定位器访问图像(img src match)。
I'm testing an internal website built on the Magento storefront. During the checkout process, certain parts of the form are hidden (style: none) until the previous section is filled out. These parts would normally break the script, but using when_present for the first element of the hidden form resolved this issue.
The Submit Order button, however, is not working well with these same methods. I worked with our lead developer today to verify that the only difference between this button and the previous form buttons is that a new page is loaded (new URL, new "done" status in the browser).
To be crystal clear:
- User enters name, address, email and clicks 'Continue' => JS "loading" animation spins while the General panel slides closed and the Shipping Method panel expands, all on the same page.
- User clicks 'Submit Order' => JS "loading" animation spins, when complete, the browser proceeds to /success/ (new page) with verifiable elements.
- If given enough time to complete (sleep statement), the test does pass.
Here is the somewhat-pseudo code for the form, and the Submit click:
def complete_form(data = {})
data = DEFAULT_DATA.merge (data)
select_guest
continue_button.click #proceed to billing panel
enter_billing_and_shipping_info(data)
enter_additional_information(data)
place_order_button.when_present.click #submit form
#sleep 2 #this succeeds, but is undesirable
thank_you_message.wait_until_present #I do not actually appear to wait until anything is present
end #
def enter_billing_and_shipping_info(data)
billing_first_name.when_present.value = data['First Name'] #I work!
billing_last_name.value = data['Last Name']
#more fields
end #
From Steps:
thank_you_message.should include("Yippee")
The script fails in two different ways depending on how quickly the site is responding:
- fail with a message that the expected Thank You message was not found - a screenshot taken during the error shows the Checkout page, NOT the thank you page, with the "loading" animation displayed. (expected "Checkout" to include "Your order has been received")
- fail with the "Element not found in the cache" error - the screenshot in this case does display the Thank You page, containing the text we are looking for
Other methods such as Watir::Wait.until, or until {} do, resulted in the same behavior.
- Windows 7 64-bit & Windows XP 32-bit
- ruby 1.9.2p290 (2011-07-09) [i386-mingw32]
- cucumber (1.0.2)
- rspec (1.3.2)
- watir-webdriver (0.3.0)
Update 8-15
Attempted solution #1:
place_order_button.when_present.click #complete form
ajax_submit_image.wait_while_present
Same end result - script terminates with no success message found, screenshot shows the Ajax loading image mid-spin. Both this and the previous method SHOULD work, but seem to have no effect. I did verify that I can access the image using the locators in the script (img src match).
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
您是否考虑过使用“加载动画”(可能只是一个动画 gif 或类似的动画)作为知道您应该继续等待的方式?
我在我的一些脚本中使用了这种方法,其中动画只是一个简单的图形文件,客户端 JavaScript 使其可见或不可见。因此,我的等待循环包括短暂的睡眠,然后检查动画是否仍然存在,一旦动画消失就退出。
Have you considered using the presence of the 'loading animation' (which might just be an animated gif or similar) as a way to know you should keep waiting?
I've used that means in some of my scripts where the animation was just a simple graphic file that was being made visible or not by client side javascript. So my wait loop consisted of a brief sleep, and checking to see if the animation was still present, exiting once it had gone away.
一个值得考虑的选项是在应用程序本身中请求一个标志的可测试性功能,让您知道异步进程是否正在运行。在我测试的一个 AJAX 密集型 Web 应用程序中,每当 XRH 或计时器启动时,我们都会在 body 标记上设置一个属性,例如 AjaxStarted,并且任何 XHR 或计时器要做的最后一件事就是将该属性设置为 AjaxStopped。这样,在任何上下文中(即使可能有多个异步进程正在进行,我也可以调用一个简单的方法来查看是否应该继续前进。
您可以在此处阅读我们所做的详细信息以及我们尝试过的其他一些解决方案:
http://testingjeff.wordpress.com/2009/10/21/relief-for-the-pain-of-waiting-for-ajax-elements-on-the-page/
one option worth considering is requesting a testability feature of a flag in the application itself that lets you know if an asynchronous process is running. In one AJAX-heavy web app I tested, whenever an XRH or timer kicked off, we set an attribute on the body tag like AjaxStarted and the final thing any XHR or timer would do was set that attribute to AjaxStopped. That way, in any context (even where there might be multiple asynchronous processes underway, I had one easy method to call to see if I should move on or not.
You can read details of what we did and some other solutions we tried here:
http://testingjeff.wordpress.com/2009/10/21/relief-for-the-pain-of-waiting-for-ajax-elements-on-the-page/