Obwohl mir bewusst ist, dass Tests zuverlässig laufen sollten, sagt meine Erfahrung: Das kann nicht immer mit vertretbarem Aufwand erreicht werden (und muss nicht durchgeführt werden; siehe meine Berechnung unten)).Cucumber.js: Geben Sie Szenarien einen zweiten Versuch
Insbesondere wenn Tests für eine bereits vorhandene Webanwendung eingeführt werden, die ständig verbessert werden muss, kann es schwierig sein, zuverlässige E2E-Tests zu erstellen. Aber im Gegensatz dazu ist es ziemlich einfach und außerdem ausreichend, Tests zu bauen, die gelegentlich abstürzen (solange sie zuverlässig ausfallen, wenn es um Erwartungen geht).
Wenn Sie Winkelmesser für E2E-Tests verwenden, haben Sie möglicherweise auch das erlebt.
Statistiken sagen mir, dass ein Test, von dem bekannt ist, dass er eine 25% ige Chance zum Absturz hat, eine Chance von 6,25% hat, zweimal zu crashen, eine 1,56% ige Chance, dreimal zu stürzen, 0,39 % Chance, viermal zu stürzen, wenn sie vier Mal ausgeführt werden, und eine Chance von 0,10%, fünf mal zu stürzen, wenn sie fünf mal ausgeführt wird (und so weiter).
Daher ist es keine große Sache, eine Reihe solcher Tests zu starten, bis jeder von ihnen es schafft, ohne Fehler zu terminieren.
Meine Anforderung ist, ein Cucumber.js-Szenario immer wieder auszuführen, bis es zum ersten Mal während eines einzelnen Feature-Laufs erfolgreich ist, und dann das Test bestanden/fehlgeschlagen-Ergebnis des nachfolgenden Laufs.
Ich habe versucht, einen After Hook zu erstellen, der das Szenario erneut ausführt, aber ich habe keine Möglichkeit gefunden, ein Szenario innerhalb des Hooks aufzurufen. Abgesehen davon habe ich keine Möglichkeit gefunden, einen Crash-Szenario-Lauf zu verwerfen.
Bitte sagen Sie mir, welche Optionen ich habe. Ich benutze Grunt, Winkelmesser und Gurke.
Da unsere Testsuite riesig ist, immer noch schnell wächst und von einem automatisierten Build-Prozess betrieben wird, brauche ich eine Möglichkeit, unzuverlässige Tests so zuverlässig wie möglich auszuführen.
Ich denke, das wird zu einer unüberschaubaren Testsuite führen. Wie werden Sie echte Fehler von Fehlern aufgrund von Blähungen unterscheiden? Sie können jeden Test nur eine bestimmte Anzahl von Malen ausführen und dann aufgeben, oder Ihre Suite wird für immer laufen. Meiner Erfahrung nach sollten Sie Tests so wenig wie möglich wiederholen, da dies es Entwicklern erleichtert, flockige Tests zu schreiben. –
"Wie werden Sie echte Fehler von Fehlern aufgrund von Schuppenbildung unterscheiden?" Wenn ich sicherstelle, dass der Test niemals erfolgreich ist, wenn die getesteten Bedingungen nicht zutreffen (indem ich auf den "Dann" -Schritt eines Szenarios achte und den "Dann" -Schritt ** sicher nicht vererbe, wenn die App etwas falsch testet) **), es ist leicht zu unterscheiden: Sobald ein Test _never_ durchgeht, muss ich das getestete Szenario manuell überprüfen. ** Wenn dies jedoch nicht der Fall ist, kann ich (so als ob ich einen Test ohne Probleme durchgeführt hätte) feststellen, dass mit dem Szenario alles in Ordnung ist. ** – ideaboxer
"Das wirst du nur sein Sie können jeden Test eine bestimmte Anzahl von Malen ausführen und dann aufgeben, oder Ihre Suite wird für immer laufen."Aufgeben, nachdem es automatisch 10 Mal (max) versucht wurde, ist keine große Sache: Sie können ein Szenario immer manuell ausführen und sehen, ob Sie das unerwartete Verhalten reproduzieren können. Da weiß ich, dass normalerweise jeder Test in _each_ run nicht abstürzt Wenn ich zweimal oder dreimal gelaufen bin, ist das absolut in Ordnung für mich. "Ein gelegentlich abstürzender, aber immer noch verlässlich fehlender Test ist immer besser als überhaupt kein Test. – ideaboxer