Wie wird ein RSpec-Test nach einer bestimmten Zeitspanne ausgeführt?

Question

Ich arbeite an RSpec Rauch Tests. Das Projekt, das ich testen muss, führt asynchrone Aufrufe durch, daher muss ich nach einer bestimmten Zeitspanne einige Testfälle durchführen.

Beispiel:

describe "Whatever Test Automation" do 
    context "When logged in .." do 
    it "does specific things" do 
     bla bla .. 
    end 

    it "does specific things 2" do 
     bla bla .. 
    end 

    end 
end 

Wie kann ich den zweiten Test nach einer bestimmten Zeitspanne laufen, sagen let`s 20 Minuten? Wenn das im Code nicht möglich ist, gibt es irgendeine Konfiguration in Jenkins?

Answer 1

Zuerst müssen Sie sicher sein, dass Testauftrag immer die gleiche ist. https://www.relishapp.com/rspec/rspec-core/v/3-0/docs/command-line/order

könnten Sie schlafen gesetzt in der Nähe von Block https://www.relishapp.com/rspec/rspec-core/v/3-4/docs/hooks/around-hooks

Spec Lauf, der als 20 Minuten länger dauert, ist ein schlechter Geruch. Ich würde nach Optionen suchen, um lange Prozess während des Tests zu verspotten. Eine andere gute Richtung könnte rspec-wait Edelstein sein, auf Behauptung zu warten, solange Sie brauchen.

P.S. In Jenkins können Sie einen Test pro Zeit mit dem Befehl rspec /spec/controllers/groups_controller_spec.rb:42 aufrufen, indem Sie einen Test pro Lauf kombinieren, um seltsame Kombinationen mit dem Schlaf zwischen Läufen zu erstellen.

Answer 2

Zwei Punkte: Dies ist wirklich ein Test, und Sie müssen einen Weg finden, um die Zeit zu reduzieren, die es braucht, um zu laufen.

In Bezug auf Teststruktur, ist Ihr zweiter Test nicht wirklich ein unabhängiger Test. Es hängt davon ab, dass der erste Test ausgeführt wurde. Die beiden sollten als ein einziger Test geschrieben werden. In RSpec werden Rauchtests wahrscheinlich am besten als feature specs geschrieben (nicht wegen der Capybara-Integration, sondern weil die feature und scenario-Syntax konzeptionell für Akzeptanztests geeignet ist). Es ist angemessen, mehr als eine Gruppe von Erwartungen in einem einzigen Szenario zu haben. So, wie ein First-Pass, würde ich schreiben:

feature "Smoke tests" do 
    context "Logged in" do 
    scenario "User starts a long-running process" do 
     # Do whatever starts the process 
     # Expect the initial (immediate) results of the process 
     sleep 20 * 60 
     # Expect the asynchronous results of the process 
    end 
    end 
end 

In Bezug auf Testlaufzeit, wäre es schrecklich sein zu haben, einen 20-minütige Einzeltest jedes Mal, wenn der Rauch testete eine Version Ihrer Software auszuführen. Alles, was Sie tun können, um diese 20 Minuten zu reduzieren, ist ein großer Vorteil für Ihr Unternehmen. Ich weiß nicht, warum es dauert 20 Minuten, den Prozess testen Sie testen, aber hier sind drei Überlegungen:

• Wenn es tatsächlich 20 Minuten Arbeit (Berechnung) ist es, den Rauch zu tun, geben Testen Sie weniger Arbeit. Wenn die Zeit zum Abschließen des Prozesses beispielsweise von der Größe der Eingabedaten abhängt, geben Sie ihr einen Mindestdatensatz für die Bearbeitung. Wenn ein Teil dieser 20 Minuten nur eine willkürliche Verzögerung ist, bieten Sie einem privilegierten Benutzer die Möglichkeit, die Verzögerung zu steuern und diesen Mechanismus in Ihrem Rauchtest zu verwenden, um die Verzögerung auf einen so kleinen Wert wie möglich zu setzen, solange sie noch aktiv ist gültig als Rauchprobe. Fügen Sie diesen Mechanismus dem Produktionscode hinzu (anstatt etwas Testspezifisches wie einen Stub auszuführen), damit der Rauchtest noch den Produktionscode testet.

• Wenn ein Teil dieser 20 Minuten einfach lange genug wartet, um sicher zu sein, dass der Prozess abgeschlossen ist, minimieren Sie dies durch Abfragen. Der von uzzer vorgeschlagene rspec-wait-Edelstein ist ein gutes Beispiel für diese Taktik. Sie könnten Ihre eigenen Abfragen schreiben, wenn der Wartealgorithmus von rspec-wait (er prüft nur alle wait_delay bis er eine wait_timeout erreicht) nicht gut für Sie funktioniert.