Travis-CI-Knotenerstellung schlägt zufällig fehl

Question

Ich habe ein Problem mit einem knotenmodul auf denen alle Tests lokal, auf anderen Boxen und auf Travis-CI funktionieren, aber manchmal und nicht aufgrund einer Zeitüberschreitung schlägt ein einzelner Test fehl Travis-CI.Der Test ist deterministisch, zumindest meiner Meinung nach, also sollte er nicht zufällig fehlschlagen.

Ich habe das Problem auf diesen Teil zurückgeführt:

function record(rec_options) {

    //  Originaly the parameter was a dont_print boolean flag.
    //  To keep the existing code compatible we take that case into account.
    var typeof_rec_options = typeof(rec_options);
    var dont_print = (typeof_rec_options === 'boolean' && rec_options)
      || (typeof_rec_options === 'object' && rec_options.dont_print);
    var output_objects = typeof_rec_options === 'object' && rec_options.output_objects;

...

        var out = !output_objects ?
          generateRequestAndResponse(body, options, res, datas) :
          generateRequestAndResponseObject(body, options, res, datas);

Für den Wert von rec_options Wesen { dont_print: true, output_objects: true }, var output_objects ausgewertet wird (wieder nur manchmal) als false die Funktion gibt also Zeichenfolgen aus und keine Objekte, bei denen der Test korrekt fehlschlägt.Der Beweis, dass die Flag-Auswertung fehlschlägt, ist in zu sehen dieser Build das gibt Zeichenfolgen anstelle von Objekten aus (außerdem habe ich einen Test, um sicherzustellen, dass der zurückgegebene Wert immer ein Objekt ist output_objects angegeben ist und das auch fehlschlägt string wo object erwartet wurde).

Meiner Meinung nach sollte das niemals passieren und output_objects ist nicht mehrdeutig definiert und schon gar nicht zufällig.Und doch passiert genau das immer wieder.

Was mache ich falsch?

Answer 1

Das Problem lag in einem der Komponententests, der nicht darauf wartete, dass der asynchrone Aufruf beendet wurde, bevor er selbst beendet wurde.Dies würde dann je nach Zeitpunkt die Ausführung anderer Tests stören.Dies ist sehr spezifisch für das betreffende Knotenmodul (NOCK), da HTTP / HTTPS-Anforderungen verspottet werden und daher nachfolgende Tests manchmal die asynchronen Anforderungen aus dem fehlerhaften Test erfassen.