La construction du nœud Travis-CI échoue de manière aléatoire

Question

j'ai un problème avec un module de nœud sur lequel tous les tests fonctionnent localement, sur d'autres boîtiers et sur Travis-CI mais parfois, et non à cause d'un timeout, un seul test échoue sur Travis-CI.Le test est déterministe, du moins selon moi, il ne devrait donc pas échouer au hasard.

J'ai retracé le problème à cette partie :

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);

Pour la valeur de rec_options être { dont_print: true, output_objects: true }, var output_objects est évalué (encore une fois seulement parfois) comme false ainsi, la fonction génère des chaînes et non des objets sur lesquels le test, correctement, échoue.La preuve que l'évaluation du drapeau échoue peut être vue dans cette construction qui affiche une chaîne au lieu d'objets (j'ai également un test pour m'assurer que la valeur renvoyée est un objet à chaque fois output_objects est spécifié et cela échoue également en affichant string où object était attendu).

Selon moi, cela ne devrait jamais arriver et output_objects n’est pas défini de manière ambiguë et certainement pas au hasard.Et pourtant, c’est exactement ce qui se produit à maintes reprises.

Qu'est-ce que je fais mal?

Answer 1

Le problème résidait dans l'un des tests unitaires qui n'attendait pas la fin de son appel asynchrone pour se terminer.Cela interférerait alors, selon le timing, avec l'exécution d'autres tests.Ceci est très spécifique au module de nœud en question (encoche) car il se moque des requêtes HTTP/HTTPS et les tests ultérieurs capturent donc parfois les requêtes asynchrones du test défectueux.