我目前使用Watir-webdriver进行所有的前端测试,但开发团队使用Capybara在Jenkins CI上运行他们的测试。我们都使用相同的Cucumber功能。
是否值得我们进行单独的测试并有效地进行两次测试?使用哪种工具更好?我已经阅读了web上所有可用的比较,并且更喜欢使用watir-webdriver,但是Capybara允许我无缝地使用headless测试。
那么有什么有用的想法和想法吗?我正处在一个十字路口,不确定是否要放弃Watir-webdriver,只与开发团队的其他成员一起使用Capybara。
发布于 2012-12-21 23:37:56
我们正在对我目前的项目进行完全相同的讨论。其中一位开发人员是Capybara的铁杆粉丝,而我熟悉的是Watir-webdriver。
水豚有一个真正的简单性,这使得它非常快地启动和运行测试,但我担心随着时间的推移会出现维护问题,我还担心它的简单性可能意味着缺乏灵活性。
Watir-webdriver允许我为我的网页编写抽象层,准确地识别我想要/需要的元素(灵活性),这也意味着对于编写测试场景的人来说,“测试”层仍然看起来很简单,比如Capybara,但随着时间的推移,维护将会很快,因为代码天生就是干燥的。编写页面元素层需要更多的前期成本,但我有一种安全感,即未来框架的维护将会很快。
当然,我是有偏见的--但思想开放。我很乐意听到一位卡皮巴拉粉丝的反驳。
发布于 2013-05-01 18:20:12
至于是否为相同的黄瓜特征使用两种不同的工具取决于测试域以及哪种工具最适合它。如果Watir-webdriver比Capybara-webdriver更适合前端测试,反之亦然。你需要花一些时间调查Capybara (一个设计高峰,使用敏捷的说法)来将它与你所习惯的进行比较。试着保持客观,即使(在我的经验中)使用一个熟悉的框架是非常困难的,然后做一个变更的成本效益分析。直接成本可能只是时间/精力,但它仍然是影响项目交付的成本。
Capybara与DRY编程并不兼容-抽象层(就像Abe在他的回复中提到的那样)可以与Capybara的自定义选择器一起使用。一旦这些都创建好了,你就可以像这样在你的自定义选择器上使用水豚查找器和匹配器了;
Capybara.add_selector(:slide_show) do
xpath { ".//div[contains(@class,'slideshow')]" }
end
Capybara.add_selector(:slide_show_element) do
xpath { ".//div[contains(@class,'slideshowelem')]" }
end允许你使用Capybara的find;
find(:slide_show_element, 'Sunset').click从Cucumber的角度来看,可以从步骤传递该定位符串;
And I Click "Sunset" in the "Holiday Pictures" Slide Show通过这样的步骤定义;
Given /^(?:I |)Click "(.*?)" in the "(.*?)" Slide Show$/i do |picture,slideshow|
within(:slide_show, slideshow) do
find(:slide_show_element, picture).click
end
end所以,问题仍然是一个过程--有两个框架会影响你的工作流程吗?调和两者会涉及不可接受的时间损失吗?
发布于 2012-12-21 23:01:39
如果你在Linux上,你可以使用watir-webdriver:http://watirwebdriver.com/headless/运行真正的浏览器
也许有一种方法可以使用watir-webdriver来运行无头浏览器,如果你想这样做的话。
根据您的上下文,是使用一个工具更好还是同时使用两个工具更好。使用这两个工具有什么问题吗?
https://stackoverflow.com/questions/13991762
复制相似问题