Mocha: - Option de commande pour une commande de test aléatoire?

meh, assez facile d'éviter les dépendances croisées sans l'aide de l'outillage

Bien qu'il soit facile to avoid cross-test dependencies without help of tooling , il est également facile d'ajouter une telle dépendance dans une suite de tests sans le remarquer. Un bogue dans la suite de tests se traduit généralement par un bogue dans un système testé. Ces bogues sont difficiles à retracer, car le code est censé être couvert par des tests.

Tester l'absence de dépendances croisées est impossible sans outillage.

@visionmedia , veuillez reconsidérer.

+1 @yanovich. J'utiliserais une option d'ordre aléatoire qui génère un numéro de graine. Cela serait très utile dans un environnement CI.

@visionmedia , les modèles mangouste fournissent un exemple simple de dépendances croisées. mongoose.model 'User', UserSchema ajoute un modèle sur le tableau de mongoose.models . Il est donc possible de créer un fichier qui repose sur le modèle utilisateur en cours de chargement dans mongoose.models. Prenez Comment.find().populate('_user').exec(cb) comme exemple. Si le test utilisateur s'exécute avant le test de commentaire, cela s'exécutera correctement, car vraisemblablement require('./models/user') (ou quelque chose), a chargé le modèle User dans mongoose.models. Mais si le test de commentaire s'exécute avant le test utilisateur, vous obtiendrez cette erreur Schema hasn't been registered for model "User" . Cela peut se produire en production lorsque l'API de commentaire s'exécute avant l'API de l'utilisateur et que le fichier de commentaire ne savait pas qu'il avait une dépendance entre fichiers.

Il est possible d'avoir toujours le problème de production avec le test fonctionnant si le fichier de test a require ('./ models / user') (ou autre) et qui charge l'utilisateur dans mongoose.models. Cependant, avoir un ordre aléatoire serait un outil plus utile pour découvrir des problèmes potentiels comme celui-ci.

J'espère bien articulé cela. Au plaisir d'entendre vos pensées.

désolé, je pense que c'est une exagération majeure, le moka est assez gonflé tel quel. S'il y avait beaucoup plus d'intérêt, cela en vaudrait peut-être la peine.

Merci d'y penser.

Comme la plupart des choses dans le code, il est facile pour les personnes qui savent d'éviter de le faire intentionnellement. Il est plus difficile d'éviter de le faire par inadvertance. Et si vous ne savez pas que c'est même un problème (c'est-à-dire des équipes d'expérience mixte), il est tout à fait probable que cela se produise :)

Il semble que bon nombre de personnes s'y intéressent (et beaucoup pensent que c'est l'une des meilleures fonctionnalités de minitest). S'il est fusionné, je serai heureux de le mettre en œuvre.

+1 intéressé.

Ce serait bien d'avoir! J'ai trouvé que mes tests échouaient en renommant les noms de fichiers, ugh.

+1 c'est important

: +1:

: +1:

+1 C'est une assez grosse lacune.

La sémantique de rspec est assez solide: vous pouvez passer un ordre de départ, ou il peut le choisir au hasard. S'il sélectionne la graine au hasard, il l'imprime, ce qui facilite la reproduction.

Il n'est souvent pas facile d'éviter les dépendances croisées. Parfois en raison d'interactions mondiales imprévues, parfois par commodité. Je soupçonne que plus de 50% des projets utilisant le moka verraient des échecs de test si l'ordre était randomisé. Voici quelques exemples qui semblent dépendre de l'ordre d'exécution du test:

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

Ces deux exemples sont répertoriés comme suites de tests exemplaires sur http://visionmedia.github.io/mocha/ et je n'ai pas passé beaucoup de temps à chercher des problèmes.

Je vais rouvrir ça. Je pense que ce serait utile. Bien qu'il existe des moyens de déterminer les tests croisés sans outillage, si nous pouvons automatiser cela, cela gagnerait du temps.

Après avoir joué un peu avec cela, cela semble non trivial en raison de la nature hiérarchique des suites. Les tests sont exécutés en se répétant dans les suites. Pour exécuter des _Tests_ de manière aléatoire, nous devions les énumérer, les randomiser, puis travailler à rebours.

Cela rendrait les hooks before() et after() quelque peu dénués de sens car ils seraient exécutés _n_ fois par _n_ tests dans une suite (ou plutôt, dans le pire cas, mais seulement si nous faisons attention ), car nous changeons continuellement de contextes. On dirait que cela entraînera une pénalité de performance.

Utiliser des semences aléatoires et signaler des semences auto-générées semble trivial, cependant, les journalistes peuvent avoir besoin de connaître ces informations, ce qui nécessite une ou plusieurs implémentations dans les journalistes.

Bien sûr, je suppose que ce que j'ai décrit ici est ce qui est demandé. Une fonctionnalité comme celle-ci nécessite une spécification.

D'autres options incluent "randomiser les suites" ou "randomiser les tests dans les suites" ou une combinaison des deux. En pratique, cela signifie que une fois que vous êtes dans un describe() _A_ bloc, vous ne pouvez pas exécuter des tests dans tous les parents ou frères et soeurs describe() bloc _B_ jusqu'à ce que tous les tests en _A_ ont été exécutés (qui semble être une implémentation beaucoup plus simple, et ne causera pas de problèmes avec before() / after() ).

Ce que je demande (et je pense que d'autres le demandent) est la plus simple des options:

• randomiser les tests au niveau le plus bas: dans un seul bloc de description; mélangez les déclarations "it".
• randomiser l'ordre des suites de niveau supérieur (ou randomiser l'ordre des fichiers qui sont chargés)

Je ne pense pas qu'il soit très utile de mélanger les choses aux niveaux intermédiaires.

Certainement un hack, mais fonctionne pour le niveau le plus bas 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)

** J'ai eu 2 échecs intermittents sur 100 exécutions de toute la suite de tests dans les deux cas.

OK, c'est certainement plus facile à mettre en œuvre!

Je regardais la bibliothèque seedrandom pour cela; utilisez l'option pass .

Accepterait PR.

Je nettoierai probablement ce code et ajusterai la suite de tests au cours des prochains jours. Le soulignement est-il trop lourd de dépendance pour cela? Je pourrais probablement utiliser quelque chose de léger comme celui-ci: http://stackoverflow.com/questions/6274339/how-can-i-shuffle-an-array-in-javascript.

@boneskull Je soutiens votre décision de rouvrir cela. : +1:

D'autres options incluent "randomiser les suites" ou "randomiser les tests dans les suites" ou une combinaison des deux.

Cela me semble plus que suffisant. Pas besoin de répéter tout en bas, d'énumérer et de mélanger.

C'est formidable d'entendre cela.

Je me demande si rspec a géré le shuffle récursif? Ça vaut peut-être la peine de regarder
à leur code?

Le mardi 26 août 2014, Joshua Appelman [email protected]
a écrit:

@boneskull https://github.com/boneskull Je soutiens votre décision de
rouvrez-le. [image:: +1:]

Les autres options incluent "randomiser les suites" ou "randomiser les tests dans
Suites »ou une combinaison des deux.

Cela me semble plus que suffisant. Pas besoin de récurer tout en bas,
énumérer et mélanger.

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/visionmedia/mocha/issues/902#issuecomment -53482124.

@syrnick Je ne voudrais pas accepter un PR avec une si grande dépendance, et utiliser à la place seedrandom . Sans cela, je ne sais pas comment vous allez soutenir l'ensemencement. seedrandom vous permet de spécifier une graine ou non, et si vous ne le faites pas, elle vous retournera une graine. Ensuite, nous pourrions l'afficher à l'utilisateur et lui permettre de le spécifier, à la RSpec.

@syrnick Rappelez- vous que si vous générez des graines, elles peuvent ne pas être «affichables» sans les transmettre aux journalistes. Je ne connais pas très bien l'architecture de reporting, je ne peux donc pas vous dire avec certitude, ni quoi faire ...

+1

Je n'ai pas regardé l'implémentation, mais +1 à l'exécution de tests aléatoires par défaut est très important.

@syrnick Veuillez me faire savoir si vous avez l'intention de le faire, merci.

Je suis heureux de le faire, mais je n'ai pas d'ETA immédiate.

: +1 :, vous avez encore besoin d'aide avec un PR?

En effet, personne ne semble avoir commencé à travailler là-dessus.

Tout d'abord, il semble qu'un mélange Fisher-Yates ferait le travail ici.

Deuxièmement, je préfère avoir --order random , --order random-suites et --order default comme trois arguments, avec un :<seed> facultatif.

+1. Je viens de trouver un bogue qui se serait manifesté il y a longtemps si les tests avaient été randomisés. Similaire à la façon dont RSpec le prend en charge.

Voici un code qui illustre l'utilité de la commande aléatoire des tests. Bien qu'il existe des exemples plus simples, c'est celui que je viens de rencontrer lors d'une démo TDD. Si vous inversez l'ordre des tests, le premier test échoue toujours.

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

J'aimerais avoir cela.

: +1:

Une fois que vous avez impliqué quelques globaux (c'est Javascript, rappelez-vous), commencez à supprimer les appels au serveur et à insérer / supprimer des éléments du DOM dans vos tests, il est _très_ facile d'ajouter une dépendance d'ordre. La randomisation de l'ordre de test aiderait à les découvrir plus tôt que plus tard.
: +1:

: +1:

: +1:

+1

L'ordre aléatoire par défaut, avec une graine facultative pour recréer l'ordre, serait une excellente fonctionnalité à avoir.

+1 pour l'avoir, mes tests échouent parfois lorsqu'ils sont exécutés dans un ordre aléatoire ...

En attendant, unix à la rescousse (Malheureusement, la graine aléatoire n'est pas prise en charge):

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

Je cherchais dans quel ordre mocha exécute les tests et a trouvé ceci. En l'absence de randomisation, quel est l'ordre d'exécution par défaut? Est-ce toujours l'ordre dans lequel les tests apparaissent physiquement dans le fichier?

: +1:

@danielabar ouais ils seront dans l'ordre dans

@NicolasJacob Eh bien, la graine aléatoire est en fait possible dans une certaine mesure, btw. :)

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

https://github.com/bahmutov/rocha fonctionne pour cela.

@boneskull bien qu'il PR Please toujours valide? Si c'est le cas, j'obtiendrai une contribution le jour suivant.

Je pense que dans la poursuite d'essayer éventuellement de garder le noyau moka minimal, l'équipe pourrait hésiter à introduire de nombreuses nouvelles fonctionnalités. La prochaine version majeure de mocha a pour objectif d'avoir une interface enfichable.

Puis-je suggérer d'utiliser simplement https://github.com/bahmutov/rocha si cela fonctionne?

Sauce incroyable

Qu'entendez-vous par interface enfichable? Sera-t-il possible d'introduire un ordre de test aléatoire via cette interface?

+1 pour la demande de fonctionnalité

@sulabhjain ,

Progrès dans cette branche .

+1 pour cette fonctionnalité

C'est vraiment l'une des fonctionnalités les plus critiques d'un framework de test pour aider à garder les tests indépendants. Chaque cadre de test JVM majeur possède cette fonctionnalité de base.

+1 pour cette fonctionnalité. Oui, il est facile d'éviter les dépendances de test avec suffisamment d'expérience et / ou de travailler seul, mais ce n'est pas toujours le cas.

Pour ceux qui sont intéressés par cette fonctionnalité, ils peuvent envoyer des PR contre la branche de randomisation pour aider à terminer ce qui reste.

+1 pour la fonctionnalité. J'apprécie vraiment qu'une succursale soit en cours pour cela.

J'attends toujours ça :))

Cela peut être vraiment utile.
@tj Je comprends qu'il est facile d'éviter les dépendances de test lorsque vous travaillez avec des personnes ayant des compétences de base sur les tests, mais parfois vous devez prendre en charge une équipe de développement et vous pouvez rencontrer des personnes n'ayant même pas les connaissances de base sur les cas de test.

En fait, cela est également utile lorsque vous reprenez des projets existants et que vous souhaitez vérifier facilement si un test est lié à celui précédent.

@boneskull Excellent travail! Quel est le statut de ce correctif? Avez-vous besoin d'aide pour quelque chose?

Je voulais juste partager ma solution temporaire que j'utilise pour exécuter des tests moka dans un ordre aléatoire. Peut-être que ce sera utile pour quelqu'un.

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

Malheureusement, cela ne mélange pas les exemples de test dans le même exemple, mais cela reste assez intelligent et pratique!

+1 à l'appui de cette fonctionnalité

C'est toujours sur la table, mais a besoin de l'attention de pas-moi

Alors, que reste-t-il réellement ici? Où puis-je commencer?

J'adorerais voir cela mis en œuvre ❤️

Je viens de trouver le package choma , qui fournit un plugin très simple pour Mocha pour randomiser l'ordre des suites de tests et des cas. Bonne alternative au rocha, qui a été mentionné plus tôt. Simple et résout le problème pour moi!

Une alternative serait d'exécuter des tests en parallèle:

• Karma (+ moka ou jasmin) - karma-parallèle - pour le moment ne prend pas en charge la couverture de code
• Mocha - mocha parallèles tests ou mocha.parallel
• Jest - fait cela par défaut