Mocha: - Bestelloption für zufällige Testreihenfolge?

meh, ziemlich einfach, Cross-Test-Abhängigkeiten ohne Hilfe von Werkzeugen zu vermeiden

Es ist zwar einfach to avoid cross-test dependencies without help of tooling , aber es ist auch einfach, eine solche Abhängigkeit in eine Testsuite einzufügen, ohne es zu merken. Ein Fehler in der Testsuite führt normalerweise zu einem Fehler in einem getesteten System. Diese Fehler sind schwer zu verfolgen, da der Code angeblich testversichert ist.

Das Testen auf das Fehlen von Cross-Test-Abhängigkeiten ist ohne Werkzeug nicht möglich.

@visionmedia , bitte überdenken.

+1 @yanovich. Ich würde eine zufällige Reihenfolge verwenden, die eine Startnummer ausgibt. Dies wäre in einer CI-Umgebung sehr nützlich.

@visionmedia, Mungo - Modelle bieten ein einfaches Beispiel von Cross-Test Abhängigkeiten. mongoose.model 'User', UserSchema fügt dem Array von mongoose.models ein Modell hinzu. So ist es möglich, eine Datei zu erstellen, die davon abhängt, dass das Benutzermodell in mongoose.models geladen wird. Nehmen Sie als Beispiel Comment.find().populate('_user').exec(cb) . Wenn der Benutzertest vor dem Kommentartest ausgeführt wird, wird dies einwandfrei ausgeführt, da vermutlich require('./models/user') (oder etwas anderes) das Benutzermodell in mongoose.models geladen hat. Wenn der Kommentartest jedoch vor dem Benutzertest ausgeführt wird, wird dieser Fehler Schema hasn't been registered for model "User" . Dies kann in der Produktion passieren, wenn die Kommentar-API vor der Benutzer-API ausgeführt wird und die Kommentardatei nicht weiß, dass sie eine dateiübergreifende Abhängigkeit aufweist.

Es ist immer noch möglich, dass das Produktionsproblem mit dem Test funktioniert, wenn für die Testdatei ('./ models / user') (oder was auch immer) erforderlich ist und der Benutzer in mongoose.models geladen wird. Eine zufällige Reihenfolge wäre jedoch ein weiteres nützliches Werkzeug, um potenzielle Probleme wie dieses zu entdecken.

Ich hoffe, das ist gut artikuliert. Ich freue mich darauf, Ihre Gedanken zu hören.

Entschuldigung, ich denke, es ist ein großer Overkill. Mokka ist so wie er ist aufgebläht genug. Wenn es viel mehr Interesse gäbe, wäre es vielleicht die Wartungslast wert.

Danke, dass du darüber nachgedacht hast.

Wie die meisten Dinge im Code ist es für Leute, die wissen, einfach, dies absichtlich zu vermeiden. Es ist schwieriger, dies unbeabsichtigt zu vermeiden. Und wenn Sie nicht wissen, dass es überhaupt ein Problem ist (dh Teams mit gemischten Erfahrungen), ist es absolut wahrscheinlich, dass es passiert :)

Es scheint, als ob einige Leute daran interessiert sind (und viele denken, dass es eines der besten Features von Minitest ist). Wenn es zusammengeführt würde, würde ich es gerne implementieren.

+1 interessiert.

Wäre schön zu haben! Ich habe festgestellt, dass meine Tests fehlgeschlagen sind, indem ich Dateinamen umbenannt habe.

+1 das ist wichtig

: +1:

: +1:

+1 Dies ist ein ziemlich großer Mangel.

Die Semantik von rspec ist ziemlich solide: Sie können einen Auftragssamen übergeben oder ihn zufällig auswählen. Wenn der Samen zufällig ausgewählt wird, wird er ausgedruckt, sodass er leicht reproduziert werden kann.

Es ist oft nicht so einfach, testübergreifende Abhängigkeiten zu vermeiden. Manchmal aufgrund unvorhergesehener globaler Interaktionen, manchmal aus Bequemlichkeit. Ich vermute, dass mehr als 50% der Projekte, die Mokka verwenden, Testfehler sehen würden, wenn die Reihenfolge randomisiert würde. Hier sind einige Beispiele, die anscheinend von der Reihenfolge der Testausführung abhängen:

https://github.com/visionmedia/mocha/blob/master/test/hook.async.js#L95
https://github.com/visionmedia/superagent/blob/master/test/node/not-modified.js#L31

Diese beiden sind auf http://visionmedia.github.io/mocha/ als beispielhafte

Ich werde das wieder öffnen. Ich denke es wäre hilfreich. Es gibt zwar Möglichkeiten, Cross-Test-Abhängigkeiten ohne Werkzeug zu bestimmen, aber wenn wir dies automatisieren können, würde dies den Menschen Zeit sparen.

Nachdem Sie ein wenig damit gespielt haben, erscheint es aufgrund der hierarchischen Natur der Suiten nicht trivial. Tests werden durch Rekursion in Suiten ausgeführt. Um _Tests_ zufällig auszuführen, müssten wir sie aufzählen, randomisieren und dann rückwärts arbeiten.

Dies würde dazu führen, dass before() und after() Hooks etwas bedeutungslos sind, da sie _n_ mal pro _n_ Test in einer Suite ausgeführt werden (oder besser gesagt, im _worst_ Fall, aber nur, wenn wir vorsichtig sind ), da wir ständig die Kontexte ändern. Klingt so, als würde es eine Leistungsstrafe geben.

Die Verwendung von zufälligen Seeds und die Meldung von automatisch generierten Seeds scheint trivial zu sein. Reporter müssen jedoch möglicherweise über diese Informationen Bescheid wissen, sodass eine Implementierung in den Reportern erforderlich ist.

Natürlich gehe ich davon aus, dass das, was ich hier beschrieben habe, gefragt ist. Eine solche Funktion benötigt eine Spezifikation.

Andere Optionen sind "Suites randomisieren" oder "Tests innerhalb von Suiten randomisieren" oder eine Kombination aus beiden. In der Praxis bedeutet dies, dass Sie, sobald Sie sich in einem describe() Block _A_ befinden, keine Tests in einem übergeordneten oder geschwisterlichen describe() Block _B_ ausführen können, bis alle Tests in _A_ ausgeführt wurden (welche) Es scheint eine viel einfachere Implementierung zu sein und wird mit before() / after() ) keine Probleme verursachen.

Was ich (und ich denke, andere fragen) danach frage, ist die einfachste der Optionen:

• randomisieren Sie die Tests auf der untersten Ebene: innerhalb eines einzelnen Beschreibungsblocks; mische "es" -Anweisungen.
• randomisieren Sie die Reihenfolge der Suiten der obersten Ebene (oder randomisieren Sie die Reihenfolge der geladenen Dateien)

Ich denke nicht, dass es viel Wert ist, Dinge auf den mittleren Ebenen zu mischen.

Sicher ein Hack, funktioniert aber für die unterste Ebene https://github.com/syrnick/mocha/compare/random_order?expand=1&w=0

mocha - fail
connect - pass
superagent - fail
express - pass** 
websocket.io - pass (can't tell for sure)

** Ich habe 2 intermittierende Fehler aus 100 Läufen der gesamten Testsuite erhalten.

OK, das ist sicherlich einfacher umzusetzen!

Ich habe mir die Seedrandom Lib dafür angesehen; Verwenden Sie die Option pass .

Würde PR akzeptieren.

Ich werde diesen Code wahrscheinlich in den nächsten Tagen bereinigen und die Testsuite anpassen. Ist der Unterstrich dafür zu stark abhängig? Ich könnte wahrscheinlich etwas Leichtes wie dieses verwenden: http://stackoverflow.com/questions/6274339/how-can-i-shuffle-an-array-in-javascript.

@boneskull Ich unterstütze Ihre Entscheidung, dies wieder zu öffnen. : +1:

Andere Optionen sind "Suites randomisieren" oder "Tests innerhalb von Suiten randomisieren" oder eine Kombination aus beiden.

Scheint mir mehr als gut genug. Keine Notwendigkeit, den ganzen Weg nach unten zu rekursieren, aufzuzählen und zu mischen.

Schön zu hören, dass dies geschieht.

Ich frage mich, ob rspec das rekursive Shuffle behandelt hat. Könnte einen Blick wert sein
an ihrem Code?

Am Dienstag, dem 26. August 2014, Joshua Appelman [email protected]
schrieb:

@boneskull https://github.com/boneskull Ich unterstütze Ihre Entscheidung zu
Öffnen Sie dies erneut. [Bild :: +1:]

Weitere Optionen sind "Suites randomisieren" oder "Tests randomisieren"
Suiten "oder eine Kombination aus beiden.

Scheint mir mehr als gut genug. Keine Notwendigkeit, den ganzen Weg nach unten zu rekursieren,
aufzählen und mischen.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/visionmedia/mocha/issues/902#issuecomment -53482124.

@syrnick Ich möchte keine PR mit einer so großen Abhängigkeit akzeptieren und stattdessen seedrandom . Ohne sie bin ich mir nicht sicher, wie Sie das Seeding unterstützen werden. seedrandom können Sie einen Startwert angeben oder nicht. Wenn Sie dies nicht tun, wird ein Startwert an Sie zurückgegeben. Dann könnten wir es dem Benutzer anzeigen und ihm erlauben, es a la RSpec anzugeben.

@syrnick Wohlgemerkt , wenn Sie Samen erzeugen, können diese möglicherweise nicht "angezeigt" werden, ohne sie an Reporter

+1

Ich habe mir die Implementierung nicht angesehen, aber +1 für zufällig angeordnete Testausführungen sind standardmäßig sehr wichtig.

@syrnick Bitte lassen Sie mich wissen, wenn Sie dies beabsichtigen, danke.

Ich mache das gerne, aber ich habe keine sofortige ETA.

: +1:, braucht ihr noch Hilfe bei einer PR?

In der Tat scheint niemand damit begonnen zu haben.

Erstens sieht es so aus, als würde ein Fisher-Yates-Shuffle hier den Job machen.

Zweitens hätte ich lieber --order random , --order random-suites und --order default als die drei Argumente mit einem optionalen :<seed> .

+1. Ich habe gerade einen Fehler gefunden, der vor langer Zeit aufgetreten wäre, wenn die Tests randomisiert worden wären. Ähnlich wie RSpec es unterstützt.

Hier ist ein Code, der die Nützlichkeit der zufälligen Testreihenfolge veranschaulicht. Es gibt zwar einfachere Beispiele, aber dieses ist mir gerade während einer TDD-Demo begegnet. Wenn Sie die Reihenfolge der Tests umkehren, schlägt der erste Test immer fehl.

game.js:

var express = require('express');
app = exports.app = express();

var sum = 0;

app.post('/bowl/:pins', function(req,res) {
    var score = parseInt(req.params.pins);
    console.log('Bowled ' + score);
    sum += parseInt(req.params.pins);
});

app.get('/score', function(req,res) {
    console.log('Sum: ' + sum);
    res.send(sum + '');
});

app.listen(process.env.PORT || 3000);

test \ gameTest.js:

var request = require('supertest'),
    should = require('should'),
    game = require('../game.js').app;

describe('a game of bowling', function() {
    describe('a gutter game', function() {
        it('should score 0', function(done){
            request(game).get('/score').expect(200, '0', done);
        });
    });

    describe('a single pin game', function() {
        it('should score 20', function(done){
            for(var i = 0; i < 20; i++) {
                request(game).post('/bowl/1').expect(200, done);
            }
            request(game).get('/score').expect(200, '20', done); 
        });
    });
});

Ich würde das gerne haben.

: +1:

Sobald Sie ein paar Globals involviert haben (dies ist Javascript, denken Sie daran), beginnen Sie, Serveraufrufe auszublenden und Dinge in das DOM in Ihre Tests einzufügen / daraus zu entfernen, ist es sehr einfach, eine Ordnungsabhängigkeit hinzuzufügen. Eine zufällige Auswahl der Testreihenfolge würde dazu beitragen, diese eher früher als später zu ermitteln.
: +1:

: +1:

: +1:

+1

Standardmäßig ist eine zufällige Reihenfolge mit optionalem Startwert zum Wiederherstellen der Reihenfolge eine großartige Funktion.

+1 um es zu haben, meine Tests schlagen manchmal fehl, wenn sie in zufälliger Reihenfolge ausgeführt werden ...

In der Zwischenzeit Unix zur Rettung (Leider wird kein zufälliger Startwert unterstützt):

mocha `ls -1 test/*.js | sort --random-sort `

Googelte für welche Reihenfolge Mokka Tests durchführt und fand dies. Wie lautet die Standardlaufreihenfolge, wenn keine Randomisierung erfolgt? Ist es immer die Reihenfolge, in der die Tests physisch in der Datei erscheinen?

: +1:

@danielabar Ja, sie werden in der Reihenfolge sein, in der sie in der Datei erscheinen.

@NicolasJacob gut, zufälliger Samen ist übrigens bis zu einem gewissen Grad tatsächlich möglich. :) :)

$ seq 10 | shuf --random-source=<(yes 2883)
1
7
3
4
6
2
10
5
9
8

https://github.com/bahmutov/rocha funktioniert dafür.

@boneskull Während dies ein altes Problem ist, ist das PR Please -Label noch gültig? Wenn ja, werde ich am nächsten Tag oder so etwas beitragen lassen.

Ich denke, in dem Bestreben, den Mokka-Kern irgendwann auf ein Minimum zu beschränken, könnte das Team zögern, viele neue Funktionen einzuführen. Die nächste Hauptversion von Mocha hat das Ziel, eine steckbare Schnittstelle zu haben.

Könnte ich vorschlagen, nur https://github.com/bahmutov/rocha zu verwenden, wenn es funktioniert?

Großartige Soße

Was meinst du mit steckbarer Schnittstelle? Wird es möglich sein, über diese Schnittstelle eine randomisierte Testreihenfolge einzuführen?

+1 für die Funktionsanforderung

@sulabhjain , frühere und folgende Unterstützer, verwenden Sie stattdessen bitte die +1 Reaktion.

Fortschritte in diesem Bereich .

+1 für diese Funktion

Dies ist wirklich eine der wichtigsten Funktionen für ein Testframework, um Tests unabhängig zu halten. Jedes wichtige JVM-Testframework verfügt über diese grundlegende Funktion.

+1 für diese Funktion. Ja, es ist leicht, Testabhängigkeiten mit ausreichender Erfahrung und / oder alleiniger Arbeit zu vermeiden, aber dies ist nicht immer der Fall.

Für diejenigen, die an dieser Funktion interessiert sind, können sie PRs gegen den Randomisierungszweig senden, um die verbleibenden Aufgaben zu erledigen.

+1 für die Funktion. Ich weiß wirklich zu schätzen, dass hierfür eine Niederlassung in Arbeit ist.

Ich warte immer noch darauf :))

Dies kann sehr nützlich sein.
@tj Ich verstehe, dass es einfach ist,

Dies ist in der Tat auch nützlich, wenn Sie vorhandene Projekte übernehmen und auf einfache Weise überprüfen möchten, ob ein Test mit dem vorherigen Test verknüpft ist.

@ Boneskull Tolle Arbeit! Wie ist der Status dieses Fixes? Benötigen Sie Hilfe bei irgendetwas?

Ich wollte nur meine temporäre Lösung teilen, die ich zum Ausführen von Mokka-Tests in zufälliger Reihenfolge verwende. Vielleicht ist es für jemanden nützlich.

mocha $(find tests/ -name *.spec.js | shuf)

Leider mischt das keine Testbeispiele innerhalb desselben Beispiels, aber das ist immer noch ziemlich clever und praktisch!

+1 zur Unterstützung dieser Funktion

Dies ist immer noch auf dem Tisch, braucht aber die Aufmerksamkeit von Nicht-Ich

Also, was ist hier eigentlich noch übrig? Wo kann ich anfangen?

Würde gerne sehen, dass umgesetzt ❤️

Ich habe gerade das choma -Paket gefunden, das ein sehr einfaches Plugin für Mocha bietet, mit dem die Reihenfolge der Testsuiten und -fälle zufällig festgelegt werden kann. Gute Alternative zu Rocha, die bereits erwähnt wurde. Einfach und löst das Problem für mich!

Eine Alternative wäre, Tests parallel durchzuführen:

• Karma (+ Mokka oder Jasmin) - karma-parallel - unterstützt derzeit keine Codeabdeckung
• Mokka - Mokka-Parallel-Tests oder Mokka.parallel
• Scherz - macht dies standardmäßig