2010-06-16 2 views
6

Ich versuche, eine Gurkenfunktion mehrmals (d. H. 500 Mal) auszuführen. Gibt es eine Möglichkeit dies zu tun, als wenn ich jedes Mal denselben Befehl eingeben muss? Ich schätze, das kann mit Rake gemacht werden? Ich bin kein Experte in der Verwendung von Rake oder Gurke.Mehrere Male eine Gurkenfunktion ausführen

Wir danken Ihnen für Ihre Hilfe.

Dank

+0

Wie ist das mit watir verwandt? –

+0

Ich kann nicht glauben, dass ich der Erste bin, der es sagt, aber: tu das nicht. –

+0

Warum nicht das tun? Wenn Sie testen und ein Test flockig ist, kann es nützlich sein, ihn fünf Mal auszuführen, um zu sehen, wie oft er fehlschlägt und ob er jedes Mal an derselben Stelle fehlschlägt. – zmorris

Antwort

8
ruby -e '500.times { `cucumber` }' 
+0

Ich bin mir sicher, dass du das auch in einem Bash-Skript machen kannst, aber ich kenne Ruby besser als Bash. – lambdabutz

+1

'für x in {1..500}; Gurke; done "sollte den Trick machen, es sei denn, Sie führen eine ältere Version von Bash aus. Es ist tatsächlich einfacher, kürzer und schneller in Ruby! – irkenInvader

+0

Und ausdrucksvoller! – lambdabutz

5

Innerhalb Rake-Datei:

require 'rubygems' 
require 'cucumber' 
require 'cucumber/rake/task' 

cuke_task = Cucumber::Rake::Task.new(:features) do |t| 
    t.cucumber_opts = "features --format pretty" 
end 

task :feature, :name, :times do |task,args| 
    puts "Executing feature: #{args[:name]} #{args[:times]} times" 
    cuke_task.cucumber_opts = "features/#{args[:name]}" 
    args[:times].to_i.times { Rake::Task[:features].execute } 
end  

Zuerst erstelle ich eine Standard-Gurken-Aufgabe, die alle meine Funktionen ausführen würde und formatiert sie für mich ziemlich.

Danach definiere ich eine Rake-Task mit dem Namen feature, die zwei Parameter name des Features und times der Ausführung akzeptieren würde.

Ich erweitern dann die Cuke-Aufgabe, um die Funktion name zu verwenden, die ich angegeben habe, und führe dann die Rake-Aufgabe wie angegeben aus.

$ rake feature['login.feature',500] 
+0

Upvoted. Wenn ich das implementierte, wenn ein Test fehlschlug, würde das Programm beenden, so dass Sie möglicherweise die Ausführungszeile in einen try catch-Block – jmccure

1

Tag Ihre Funktion mit so etwas wie: @ AndIwillwalk500miles

@AndIwillwalk500miles 
Feature: Walk A Mile 
    'That I can walk a mile in another man's shoes.' 

    Scenario: That I can walk a Mile in loafers 
    Given I am wearing loafers 
    And I start at point A 
    When I walk a mile 
    Then I am at point B 

erstellen Rubin-Datei in Ihrem features/support/ Ordner. Konvention scheint env.rb oder hooks.rb zu sein, aber es ist egal, wie Sie es nennen, solange es in diesem Ordner ist. Ich rufe meine env.rb. Geben Sie den folgenden Code ein:

Around('@AndIwillwalk500miles') do |scenario, block| 
    500.times { block.call } 
end 

Wenn Sie fertig sind, entfernen Sie das Tag. Wenn Sie nur ein Szenario von Ihrem Feature ausführen möchten, markieren Sie es stattdessen. Auf diese Weise können Sie 500 Mal so viele oder so wenige Tests ausführen, wie Sie möchten, ohne Rake oder Unordnung mit der Befehlszeile verwenden zu müssen. Dies ist besonders nützlich, wenn Sie zwischen Betriebssystemumgebungen wechseln.

+0

wickeln müssen, wäre es noch besser, wenn der Around-Hook Regex nehmen und die Zeiten vom Tag analysieren könnte! Oder wenn wir die Zeiten von der Kommandozeile bekommen können. –

-2

Dies ist eine dumme Arbeit um, sondern versucht, diese

Gurke Funktionen/file.feature Funktionen /../ Funktionen/file.feature

, solange der Pfad zu Datei ist jedes Mal nicht identisch Dies kann auch erreicht werden, indem ein Szenario Kontur und verschachtelte Schritte können Sie auf so viele tack „..“, wie Sie

3

wollen:

erstellen Szenario Kontur mit N Beispielen. Das Szenario wird N-mal ausgeführt.

Feature: Login Robustness 

    Scenario Outline: I want to be assured that login works consistently 
    When i run login # "<login>" repeatedly, it never fails 

    Examples: 
    | login    | 
    | repeated login # 1 | 
    | repeated login # 2 | 
    | repeated login # N | 
      … 

Nutzen Sie Ihre bestehenden Schritte als verschachtelte Schritte innerhalb des Szenarios Umriss Sie definieren:

When(/^i run login \# "(.*?)" repeatedly, it never fails$/) do |login_run_number| 
    puts login_run_number 
    steps %{ 
    Given I am at initial login, Core 
    When A correct username and password are entered, Native (Core) 
    Then I should be logged in, Native (Core) 
} 
end 

Vorteile:

  • Nur ein Bericht für den gesamten Testlauf geschrieben wird; Es gibt keine N Berichte, durch die man graben kann, um die Ergebnisse zu sehen.
  • Es verwendet vorhandene Gurkenfunktionalität; Es sind keine Änderungen am Framework erforderlich.
  • Tester wissen bereits, wie Scenario Outlines funktioniert.

Nachteile:

  • Hässlich, mehrzeilige .feature Datei.