【问题标题】:Is there a way to make cucumber try a scenario again before moving on to the next scenario有没有办法让黄瓜在继续下一个场景之前再次尝试一个场景
【发布时间】:2014-02-01 06:37:11
【问题描述】:

我正在尝试清理工作中的功能套件,我想知道是否有办法让 cucumber 重复一个场景并查看是否通过,然后再转到功能中的下一个场景? Phantom 是我的无头 webkit 浏览器 poltergeist 是我的驱动程序。

基本上,我们的构建一直失败,因为盒子被所有测试压得喘不过气来,并且在某个场景中,页面没有足够的时间来呈现我们正在尝试测试的任何内容。因此,这会产生误报。我不知道有什么方法可以预测什么测试会挂起构建。

最好在每个场景之后都有一个钩子(一个想法)。如果场景通过,那么很好地打印该场景的结果并继续前进。但是,如果场景失败,请尝试再次运行它,以确保它不会让构建变得头晕目眩。然后,只有这样,您才会打印该场景的结果并继续进行下一个测试。

有人知道如何实现吗?

我在想类似的事情

 After do |scenario|
     if scenario.failed?
         result = scenario.run_again # I just made this function up I know for a fact this doesn't actually exist (see http://cukes.info/api/cucumber/ruby/yardoc/Cucumber/Ast/Scenario.html)
         if !result
            Cucumber.wants_to_quit = true
         end
     end
 end

我看到的最初解决方案是:How to rerun the failed scenarios using Cucumber?

这很好,但我需要确保

 cucumber @rerun.txt

如果测试通过,实际上更正了报告。喜欢

 cucumber @rerun.txt --format junit --out foo.xml

哪里 foo.xml 是 junit 报告,最初说功能 1、2 和 5 正在通过,而 3 和 4 失败,但现在会说 1、2、3、4 和 5 正在通过,即使 rerun.txt只说重播3和4。

【问题讨论】:

  • 听起来你在这里有一个负载能力问题是真实的。如果您的测试环境被一些黄瓜测试所淹没,那么如果多个用户碰巧同时命中它,真实环境有什么机会。也许重点应该放在更像生产的更强大的测试服务器上,或者解决在可能相当适中的负载下的站点性能问题(这毕竟是功能测试,而不是负载测试,有多少测试正在运行同时?)
  • @mpdunson 您是否碰巧找到了方法?我基本上知道这里的cucumber re-run 命令,但这对我不起作用。由于应用程序的设计方式,我拥有的测试相互依赖。所以我所有的测试都失败了,如果第二个测试用例由于某种原因失败了。我一直在寻找与您类似的方法,如果我可以运行该特定场景直到它通过,然后再进行下一个?而不是在步骤中使用untilunless 循环。有什么想法吗?

标签: testing cucumber hook suite


【解决方案1】:

我广泛使用 rerun,是的,它确实将正确的特征输出到 rerun.txt 文件中。我有一个 cucumber.yml 文件,它定义了一堆“配置文件”。注意重新运行配置文件:

    <%
rerun = File.file?('rerun.txt') ? IO.read('rerun.txt') : ""
rerun_opts = rerun.to_s.strip.empty? ? "--format #{ENV['CUCUMBER_FORMAT'] || 'progress'} features" : "--format #{ENV['CUCUMBER_FORMAT'] || 'pretty'} #{rerun}"
%>

<% standart_opts = "--format html --out report.html --format rerun --out rerun.txt --no-source --format pretty --require features --tags ~@wip" %>
default: <%= standart_opts %> --no-source --format pretty --require features


rerun: <%= rerun_opts %> --format junit --out junit_format_rerun --format html --out rerun.html --format rerun --out rerun.txt --no-source --require features

core: <%= standart_opts %> --tags @core
jenkins: <%= standart_opts %> --tags @jenkins

所以这里发生的是我运​​行黄瓜。在初始运行期间,它会将所有失败的场景放入 rerun.txt 文件中。然后,之后,我将使用以下命令仅重新运行失败的测试:

cucumber -p rerun

唯一的缺点是它需要一个额外的命令(当然,您可以自动化)并且如果您有测试指标,它会使测试指标变得混乱。

【讨论】:

  • 感谢您的回答。我刚刚投了赞成票。我会尝试它并在它工作后接受答案。
  • 一个问题是我们的构建没有看到之前的一些成功。当它写入 junit_format_rerun 时,它会覆盖之前的内容。因此,除非特征文件中的所有特征都在同一次传递中传递,否则某些信息会丢失。黄瓜和/或第三方库中是否有一个附加格式化程序,它编写了一个足够智能的黄瓜格式化程序,知道在哪里放置成功的功能?我可以写一个放在 github 上,但我认为其他人可能已经遇到过这个问题。
  • 还有。您如何处理跳过的功能?那些似乎没有登录 rerun.txt。
  • 也许我没有正确理解您的问题,但您为什么要在重新运行时记录跳过的功能?如果该功能有一个被跳过的标签,它将永远不会被重试(因此,不会在 rerun.txt 中登录)。
  • 关于以前的成功,您是对的。我不确定是否已经有东西可以处理这个问题,所以你必须调查那个。但是,您为什么要查看/记录您以前的成功(在终端之外)?重新运行的目标是只记录失败的场景,以便它可以重新运行。
猜你喜欢
  • 1970-01-01
  • 2017-09-14
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2019-12-15
  • 1970-01-01
  • 2020-09-24
  • 1970-01-01
相关资源
最近更新 更多