Vous feriez mieux de créer deux répertoires parallèles, l'un pour les tests et l'autre
pour les fichiers de données. C'est ce que j'ai fait.
Am 04.03.2015 15:52 schrieb "Kyle P Davis" [email protected] :

Je souhaite pouvoir fournir un modèle d'exclusion afin de pouvoir
uniquement les fichiers de test qui correspondent à mon modèle de fichier de test. Cela permettrait aux données
fichiers à coexister avec les fichiers de test tant qu'ils suivent un
modèle.

Je pense que ce serait simplement fournir une option qui définit l'option Ignorer
dans glob.

Pensées? Je peux faire un PR pour cela très rapidement si vous le souhaitez.

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/mochajs/mocha/issues/1577.

Je pourrais (et je l'ai fait dans le passé) mais je préfère ne plus avoir à faire ça maintenant que j'ai réalisé que glob ignore est juste là.

Il devrait être assez facile d'ajouter un argument de ligne de commande pour définir l'option glob ignore. Je voulais juste avoir des idées et discuter un peu en premier.

Des objections à ce que je crée un PR pour cela?

J'avais juste besoin de ça aussi et j'ai été surpris de voir que le moka ne l'avait pas déjà. Je pense que ce serait un excellent ajout. Nous avons un "testApp" dans notre dossier de test que nous utilisons spécifiquement pour les tests. Nous ne voulons pas que mocha essaie d'exécuter des tests dans ce dossier. Ce serait bien de pouvoir simplement ajouter une exclusion à notre fichier mocha.opts pour exclure ce chemin spécifique plutôt que d'avoir à inclure explicitement tous les autres sous-dossiers de test que nous avons.

Bien que nous puissions déplacer le testApp, il ne rentre vraiment nulle part ailleurs dans le dépôt et son chemin relatif vers certains fichiers dans le dossier de test.

Je pense que ce serait un bel ajout. Certainement pas critique, mais utile.

@KylePDavis @toddbluhm

Si j'avais besoin de ça, je pense que je

$ mocha $(find test/ ! -path '*testApp*')

Je ne suis donc pas vraiment ravi de l'idée. Je suis un peu sur la clôture de l'existence même du drapeau recursive , puisque la même chose peut être réalisée avec une commande shell, Makefile , Gruntfile.js , gulpfile.js , etc., etc.

Je pense que @boneskull fait un bon point - c'est déjà réalisable de différentes manières. Et cela n'inclut pas le fait que vous pouvez structurer vos répertoires pour éviter cela complètement. Par exemple, étant donné cette structure:

$ tree .
.
└── spec
    ├── fixtures
    ├── integration
    └── unit

4 directories, 0 files

Vous venez de mettre à jour votre package.json pour pouvoir exécuter simplement npm test

  "scripts": {
    "test": "mocha spec/unit spec/integration"
  }

Ou avec une structure comme la suivante:

$ tree .
.
└── src
    └── models
        ├── user.js
        └── userSpec.js

2 directories, 2 files

Vous pouvez exécuter des spécifications de la même manière que l'exemple de @boneskull (cela ne lancera que les fichiers contenant Spec )

  "scripts": {
    "test": "mocha $(find src -name '*Spec.js')"
  }

Edit: corrigé :)

@danielstjules Je pense que cela atteindra n'importe quel répertoire avec Spec dans le nom. Peut-être que vous voulez -name '*.spec.js'

Ouais, tu as raison! PET de cerveau. Merci d'avoir fait remarquer cela.

Commande fixe pour l'exemple:

  "scripts": {
    "test": "mocha $(find src -name '*Spec.js')"
  }

Je pense qu'il existe encore un cas d'utilisation valide pour cette fonctionnalité: j'ai tendance à regrouper mes fichiers par fonctionnalité, donc chaque fichier de test est à côté des fichiers contenant la logique qu'ils testent. Nommer les fichiers de test fonctionne toujours avec l'argument file ou l'option grep mais je voudrais ignorer explicitement des choses comme node_modules .

Pour tous ceux qui cherchent - gulp-mocha peut y parvenir, je déteste simplement inclure gulp là où je n'ai pas à le faire.

J'aimerais prendre un moment et attribuer +1 à cette idée. Contrairement aux projets JavaScript typiques, j'aime suivre la façon dont GO effectue les tests unitaires et j'inclus un fichier de spécifications à côté de chaque fichier qui est testé. Par exemple, un répertoire dans l'un de mes projets peut ressembler à ceci:

main.js
main.spec.js
utilities.js
utilities.spec.js

Je trouve que ce type d'organisation facilite la recherche de tests plutôt que de fouiller dans un seul répertoire de fichiers de test; vous vous attendez toujours à ce que le test se trouve juste à côté du fichier qu'il teste et mes scripts de script de construction tous les fichiers .spec.js dans la version déployée.

En raison de ma disposition non standard, ce que j'aimerais pouvoir faire est d'exécuter tous les tests unitaires avec tous mes dossiers à l'exclusion du répertoire node_modules.

Je n'ai pas de boîte Windows à proximité pour le moment, mais je ne suis pas sûr si cette syntaxe de recherche fonctionnerait ou non dans Windows; une option d'exclusion serait de toute façon beaucoup plus intuitive à mon avis. De plus, presque tous les frameworks de tests unitaires incluent de toute façon un moyen d'ignorer les fichiers, donc la parité serait bien.

Salut, tous mes tests prennent en charge le format *.test.js . Ils sont tous dans le répertoire tests . Actuellement, j'ai quelques tests que je veux exclure, et je conserve toujours le chemin par défaut pour mocha qui est ./test/**/*.js . Comment je fais ça?

La création de deux répertoires séparés ne fonctionnera pas ici, et vous devez accepter que déplacer les tests entre les répertoires créerait beaucoup de bruit dans VCS.

@calebthebrewer Heureusement, j'utilise

+1 @calebthebrewer

Angular 2.0 et Polymer m'ont mis en mode composant donc je suis d'accord avec @KrisSiegel. La conservation de tout votre code dans des bundles permet de conserver une hiérarchie de fichiers propre, modulaire et facile à entretenir.

Y a-t-il un problème prévisible au chargement des tests à l'aide de la bibliothèque q promise d'une manière comme celle-ci:

import q from 'q';

import authRouterTest from '../app/routes/_authentication.router.e2e.js';

import productRouterTest from '../app/routes/_product.router.e2e.js';

import productModelTest from '../app/models/product.model.spec.js';

// Dynamically constructed sequence of functions
let funcs = [ productModelTest(), authRouterTest(), productRouterTest() ];

// This function takes an array of promise-producing functions and
// runs them sequentially.
let execTests = () => {

    let result = q();

    funcs.forEach((f) => {

        result = result.then(f);
    });

    return result;
};

// Execute tests
execTests();

De cette façon, vous pouvez importer vos fichiers de n'importe où et avoir juste un fichier de test dans test/ .

Vous pouvez résoudre la promesse dans le dernier bloc de test et terminer chaque test comme ceci

import q from 'q'

export default () => {

    let Q = q.defer();

    describe('something', () => {

        it('should', (done) => {

            ...
        });
    });

    describe('something', () => {

        it('should', (done) => {

            ...
        });

        it('should', (done) => {

            ...

            Q.resolve('test complete');
        });
    });

    return Q.promise;
};

Cela semble fonctionner plutôt bien, sauf s'il y a quelque chose que je ne considère pas.

Nous devrions toujours avoir un ignorer pour le glob. L'utilisation des commandes bash n'est pas une solution multiplateforme.

+1

Je voudrais vraiment exclure node_modules . Exclusion semble être un compagnon très pratique de recursive .

@godspeedelbow Pourquoi ce répertoire particulier devrait-il être explicitement ignoré? Normalement, je n'entends pas dire que node_modules se trouve dans un répertoire de test.

FWIW, je pourrais vraiment l'utiliser aussi. J'ai quelques projets où les tests échelonnent beaucoup plus que la bibliothèque elle-même, et cela me permettrait de mieux les organiser (les appareils appartiennent à un répertoire de test à mon humble avis).

Ignorer node_modules devient important lorsque vous faites quelque chose d'inattendu (comme moi, où je garde les fichiers de spécifications à côté du fichier qu'il teste au lieu de les garder dans un seul dossier, loin du code qu'il teste) ou si vous le souhaitez pour exécuter des tests unitaires sur un projet principal et certains de ses projets inclus (ce sont peut-être des bibliothèques internes, pas dans le repo npm, que vous souhaitez tester) mais vous ne souhaitez pas exécuter les tests unitaires dans leurs propres dépendances .

Ce problème existe depuis presque un an maintenant, donc je n'ai pas beaucoup d'espoir qu'il soit mis en œuvre. Il est important, à mon avis, de l'implémenter car les solutions de contournement nécessitent des commandes de terminal spécifiques à la plate-forme ou vous spécifiez explicitement des modèles pour chaque répertoire que vous souhaitez tester (des répertoires supplémentaires doivent donc être ajoutés au script de test). Je le ferais et le ferais moi-même, mais utiliser la méthode hacky de spécification de chaque répertoire et d'un modèle est juste plus facile que de trouver le temps de l'implémenter dans mocha.

@KrisSiegel Vous pouvez toujours faire src/**/*.js et src/**/*.spec.js . Je vois cela plus souvent dans les projets Go et Rust qu'en commençant à la racine du projet. En fait, ce dernier est relativement rare.

Bien que je pense qu'ils attendent juste que quelqu'un prenne le temps de le faire eux-mêmes. Cela ne semble pas être un patch difficile à créer (à moins que cette logique ne soit un désordre de machine à états de code spaghetti).

Je ne suis pas aussi motivé à faire cela personnellement parce que je travaille en fait sur mon propre cadre de test, destiné à être une alternative complète à Mocha, Jasmine, Tape, etc., bien que plus simple et plus puissant à la base. C'est encore trop de travail en cours, même pour les projets de jouets ATM.

J'utilise Mocha pour démarrer efficacement le framework. J'ai d'abord utilisé Chai pour les assertions jusqu'à ce que celles-ci soient stabilisées (elles sont pratiquement verrouillées sur l'API maintenant, puisque j'utilise les assertions du framework pour se tester).

Oui, c'est une solution de contournement.Je ne vois tout simplement pas beaucoup de projets JavaScript structurés de cette façon, bien que l'on puisse dire la même chose de l'association de la spécification et du fichier source. J'utilise essentiellement ce modèle, mais lorsque j'entre dans des projets déjà assez volumineux avec leurs propres systèmes de construction personnalisés, il n'est pas toujours facile de le changer.

Exclure est un modèle assez basique utilisé par de nombreux utilitaires. Je pense que le moka en a besoin :). Bien que j'imagine mon impression, puisque ce problème a été résolu en fonction de solutions de contournement spécifiques à la plate-forme, il n'était pas souhaité par rapport à l'attente d'un correctif. Si c'est quelque chose que les gens du moka voudraient réellement, si ce n'est pas fait dans quelques semaines, je pourrais certainement créer un patch.

@KrisSiegel Je suis à peu près sûr que si quelqu'un créait un correctif, il serait probablement fusionné, du moment qu'il n'impliquerait pas une syntaxe spéciale ou non intuitive. FWIW, il n'y a pas encore de PR pour _ce_, et la raison pour laquelle ce problème a été fermé était assez faible si vous considérez la plate-forme dépendante . Et je ne vois pas beaucoup d'utilisateurs Windows prêts à installer GNU find juste pour exécuter quelques tests.

Il peut être fermé, mais une situation similaire se produit déjà pour Node avec des travailleurs Web , bien que l'implémentation de Node déviera légèrement ( problème fermé , PR en cours ).

+1 pour ce que ça vaut. Un projet que j'ai construit ne nécessite pas src dossier app ou src , mais a à la place une quantité variable de dossiers nommés avec différentes implémentations d'interface. Je voudrais également garder mes tests groupés pour chaque interface, et ne pas être obligé d'utiliser un seul dossier pour les tests.

Être capable de spécifier des fichiers à ignorer avec une option .mochaignore ou une autre option serait idéal, car de cette façon je pourrais simplement l'exécuter avec un **/*.spec.js glob et ne pas craindre qu'il puisse inclure des tests du node_modules dossier.

Presque tous les autres outils de construction le permettent, nous avons .npmignore , .gitignore , .jshintignore , et jscs fournit une option pour le configurer via .jscsrc . Il serait utile que Mocha le prenne également en charge, car de plus en plus de personnes se tournent vers l'organisation des fichiers et des dossiers de composants / fonctionnalités, loin de l'approche du tiroir à chaussettes.

@isiahmeadows comme d'autres l'ont mentionné, je suis coincé avec une structure de dossiers que je ne peux pas facilement changer, donc services/ , routes/ , etc. sont à la racine du projet tout comme node_modules est. Je me suis inspiré de placer les fichiers de test à côté des fichiers qu'ils testent. Cela fonctionne très bien, mais j'ai besoin d'un troisième outil (que ce soit en ligne de commande, ou gulp, ou autre chose) pour exclure node_modules afin que seuls mes propres tests soient testés.

J'adorerais l'implémenter moi-même en moka, si je savais par où commencer :)

@godspeedelbow @adambuczynski Une solution temporaire :)

  "scripts": {
    "test": "mocha $(find . -name '*.spec.js' ! -ipath '*node_modules*')"
  }

Salut @danielstjules merci! J'ai essayé, mais pour une raison quelconque, find . -name '*.spec.js' ! -ipath '*node_modules*' ne trouve qu'un seul fichier de test.

Avez-vous mis à jour '*.spec.js' pour qu'il corresponde au modèle suivi par vos tests? Par exemple, pour faire correspondre les fichiers _all_ js, vous utiliseriez:

  "scripts": {
    "test": "mocha $(find . -name '*.js' ! -ipath '*node_modules*')"
  }

@danielstjules applaudit, mais cela ne fonctionnerait pas sur Windows, je crois, et même si pour cette application ce n'est pas un problème, j'hésite à la mettre.

En attendant, j'ai eu recours au déplacement du code et des tests de l'application dans un sous-dossier app afin que je puisse cibler ce dossier pour les tests et ne pas me soucier de node_modules ou d'autres dossiers.

@danielstjules ouais, tous les fichiers de test sont au format *.spec.js . Pour une raison quelconque, cela n'a pas fonctionné plus tôt, mais maintenant quand cela fonctionne sans problème. Merci pour ce travail * NIX.

Je veux voir cela fait pour un prochain majeur; soutenir spécifiquement .mochaignore me semble raisonnable

@boneskull Merci, ce serait génial.

Pour la prochaine version majeure, envisageriez-vous également la mise en œuvre d'un .mocharc plus "standard" pour passer des options, qui peut être placé à la racine du projet, plutôt que d'avoir à utiliser un mocha.opts dans le dossier test ?

Cela rendrait la configuration de Mocha beaucoup plus facile et conforme à la façon dont cela se fait avec d'autres outils. De plus, cela ne nous obligerait pas à avoir un dossier test juste pour le mocha.opts . (Nous mettons tous nos tests à côté des modules qu'ils testent).

@adambuczynski absolument. Je ne suis pas fan de mocha.opts

@adambuczynski excellent commentaire. Je suis d'accord, j'aimerais aussi avoir un fichier d'options standard .mocharc, je n'utilise plus de répertoire de test non plus, car il est si agréable de garder les tests à côté du code.

+1, je pense que l'exclusion est vraiment nécessaire.

@adambuczynski @boneskull La documentation indique que vous pouvez utiliser --opts pour spécifier n'importe quel chemin vers votre fichier opts, bien qu'elle ne donne aucun exemple. J'utilise ceci dans mon projet actuel et je peux confirmer que cela fonctionne comme mocha --opts .mocharc

Merci @GRUBES. En fin de compte, j'ai continué à utiliser le dossier test car j'y place également mes assistants de configuration de test, mais il est bon de savoir que c'est possible.

Glob a une option ignore, donc cela ne devrait pas être un gros problème d'ajouter simplement une option d'exclusion et de la transmettre à glob ignore.

ignore Ajoutez un motif ou un tableau de motifs glob pour exclure les correspondances. Remarque: les motifs ignorés sont toujours en mode point: vrai , quels que soient les autres paramètres.

Je ne sais pas pourquoi cela prend plus d'un an. :-)

@ inf3rno BTW, cela aurait probablement été résolu beaucoup plus tôt si quelqu'un s'était réellement assis et avait écrit le patch.

@isiahmeadows Oui , mais ce ne sera pas moi. :RÉ

Alors, cela a-t-il encore besoin d'un PR? Je serais heureux d'ajouter ceci, car je préférerais utiliser la colocation de fichiers de test au lieu des répertoires multiples pour test et test-integration

2036, qui est pour fondamentalement le même genre général de chose seulement un fichier plutôt qu'une option de ligne de commande, a un PR # 2173

Peut-être que c'est bien d'ajouter une option comme --exclude .

Ou supportez quelque chose comme mocha test/*.js !test/_*.js

Compris Glob out: mocha "./{,!(node_modules)/**/}*.test.js" pour obtenir tous les fichiers * .test.js sauf dans node_modules, et mocha "./test/**/!(notThisOne).js" pour tout récupérer dans le dossier de test et les sous-dossiers sauf notThisOne.js

Voir également:
https://github.com/isaacs/node-glob#glob -primer
https://github.com/isaacs/node-glob/issues/62

@ScottFreeCode

Lors de l'exécution dans le terminal, je reçois

mocha "./{,!(node_modules)/**/}*.test.js"
-bash: !: event not found

Ce personnage doit-il être échappé?

@mdumouchel Utilisez des guillemets simples. Sinon, oui.

@isiahmeadows

Erreur toujours

node_modules/mocha/lib/utils.js:630
        throw new Error("cannot resolve path (or pattern) '" + path + "'");
              ^
Error: cannot resolve path (or pattern) './{,!(node_modules)/**/}*.test.js'

J'ai fini par utiliser simplement la commande find

mocha $(find . -type d -name node_modules -prune -o -name '*.test.js')

@mdumouchel Si vous utilisez la version 2.x (c'est-à-dire ce qui est sur npm), cela ne fonctionnera pas de toute façon. Le support commencera dans 3.x, IIRC.

C'est bizarre, je pensais avoir essayé dans Bash et être capable d'utiliser des guillemets doubles. Quelqu'un connaît-il une syntaxe / échappement qui fonctionnera à la fois sous Windows et dans Bash?

De plus, je suis à peu près sûr que l'erreur «impossible de résoudre le chemin» signifie que le chemin ne correspond à aucun fichier de votre projet; le chemin que j'ai donné fonctionnait dans la version actuelle lorsque j'avais des fichiers de test avec des noms se terminant par ".test.js" à côté des fichiers source correspondants, à moins que je ne me trompe en le copiant de mon test dans le commentaire du problème ...

Voir # 2173

Eslint fait un excellent travail en ignorant les fichiers avec --ignore-path (et .eslintignore ).
Voir: http://eslint.org/docs/user-guide/command-line-interface#ignoring -files

Quelque chose de similaire pour le moka serait génial: two_hearts:

Ma solution de contournement:

eslint "test/!(fixtures)/**/*.js" "test/*.js"

Ma structure de fichiers

.
└── src
└── test
    └── fixtures
        └── data.js
    ├── foo.js
    └── bar.js

Problème: Mocha me donne un Error: cannot resolve path (or pattern) si l'un des 2 chemins ne correspond pas à quelque chose.:

OK, alors je cède. Ce n'est tout simplement pas convivial.

C'est ce que je pense que nous devrions faire:

1. Soutien --exclude <glob-or-path>
2. Prise en charge d'instances _multiple_ de --exclude
3. Combinez toutes les options --exclude avec tous les arguments non-option dans une seule liste (essentiellement ce que fait
4. Chargez ces fichiers

Actuellement, nous prenons en charge _n_ arguments sans option, qui peuvent tous être des globes, mais ce n'est que _additif_; cela ne fonctionne pas comme prévu:

$ mocha 'src/**/*.spec.js' '!src/forbidden/**/*.spec.js'

Donc, ce qui précède devrait fonctionner, et --exclude n'est vraiment que du sucre pour ! .

De plus, la prise en charge de .mochaignore (# 2036) sonne bien, mais c'est un problème distinct. Il devrait y avoir un module 3p que nous pouvons insérer pour avoir .gitignore comportement semblable à

... et si ce n'est pas clair, n'utilisez pas de globes sans guillemets sur la ligne de commande; voir # 2355

Étonnamment, il n'y a toujours pas d'option comme --ignore-path , en plus de placer tous les tests dans un dossier tests , il n'y a aucune raison pour laquelle nous ne pouvons pas mettre de tests avec des modules.

+1
ignorer les fichiers ou répertoires par motif est une fonctionnalité très utile

@isiahmeadows

Vous pouvez toujours faire src / / .js et src / /.spec.js

Non, vous ne pouvez pas - la correspondance de motif **/* est interrompue et ne fonctionne pas de manière récursive.

EDIT: @ScottFreeCode a la réponse ci-dessous

la correspondance de motif **/* est interrompue et ne fonctionne pas de manière récursive.

Vos chemins sont-ils cités ?

+1

Comme décrit dans https://github.com/zinserjan/mocha-webpack/issues/124 :

À l'intérieur de src/ il y a un fichier appelé server.ts qui déclenche un serveur express et s'exécute en arrière-plan. Le serveur est généralement opérationnel lors de l'exécution de la couverture, le port est donc déjà utilisé.

Nous ne voulons donc pas que ce fichier et ce fichier soient exclus.

http://remarkablemark.org/blog/2017/02/07/mocha-glob-pattern/

Exprimant mon opinion sur le fait que le moka doit être ignoré car même après tout ce temps, les responsables ont encore besoin d'être convaincus.

Le moka est canon. pourquoi ne pas élever la barre pour l'ensemble de fonctionnalités multiplateformes du framework de test que tous les autres frameworks de test aspirent à être? Nous devrions cesser d’aspirer à tout laisser à Bash. C'est déjà 2017.

Je ferai également remarquer que les utilisateurs de Windows n'ont rien d'équivalent au !(glob) Bash (qui est en fait un Bash-ism, pas même le standard POSIX).

Il ne devrait y avoir aucune dépendance Bash dans le globbing de Mocha tel quel, car il est traité par le module Glob JS. (Remarque: il peut être nécessaire de citer les chemins pour éviter que le shell ne traite les globs différemment de la façon dont Mocha le ferait, par exemple ** sans l'extension globstar ou quoi que ce soit qui rend cela spécial.)

@ScottFreeCode Utilisez-vous extglob: true lorsque vous utilisez glob? Si tel est le cas, cela peut être fermé avec cette syntaxe comme solution de contournement (puisque glob / minimatch le prend en charge avec cette option activée).

Il semble que nous ne faisons que passer le chemin de glob . Je suis presque sûr que la négation fonctionne à travers un modèle global à un moment donné, mais cela peut avoir été une version plus ancienne du module? Dans tous les cas, nous avons des tests pour le comportement à double étoile , donc si quelqu'un veut soumettre des tests pour confirmer que certains modèles de négation fonctionnent aussi (ou si quelqu'un trouve des failles dans les tests de globbing que nous avons déjà), ce serait génial .

Cependant, il y a un avantage certain à avoir une option explicite ignore / exclude . De multiples avantages, en fait:

• moins obscur
• plus facile à éviter les conflits avec les caractères spéciaux et les règles de citation de différents systèmes d'exploitation
• une liste d'inclusion moins une liste d'exclusion est plus simple dans de nombreux cas qu'une liste d'inclusion avec des éléments annulés

Je voulais simplement préciser que le statu quo n'est pas censé reposer sur une coquille en particulier. ; ^)

une liste d'inclusion moins une liste d'exclusion est plus simple dans de nombreux cas qu'une liste d'inclusion avec des éléments annulés

C'est vrai, et j'avais presque oublié ça 😄

Quiconque aborde ce problème:

La solution de contournement consiste maintenant à utiliser des globs, car cela doit être pris en charge. Si quelqu'un veut ce comportement particulier , veuillez envoyer un PR.

L'option --exclude fonctionne-t-elle?
Impossible de le trouver dans la documentation .

@ sepo-one J'ai ouvert PR pour mettre à jour le document.
Vous pouvez voir toutes les options disponibles vis- mocha -h vis de

Oui, j'utilise une ancienne version de moka. L'option mise à niveau et --exclude est là.
Les documents devraient être mis à jour de toute façon, je suppose.

Merci @outsideris