Sie können besser zwei parallele Verzeichnisse erstellen, eines für Tests und das andere
für Datendateien. Das ist, was ich tat.
Am 04.03.2015 15:52 schrieb "Kyle P Davis" [email protected] :

Ich möchte die Möglichkeit haben, ein Ausschlussmuster bereitzustellen, damit ich es kann
Nur Testdateien, die meinem Testdateimuster entsprechen. Dies würde Daten ermöglichen
Dateien, die mit Testdateien koexistieren sollen, solange sie einem vernünftigen Wert folgen
Muster.

Ich denke, dies wäre einfach eine Option, die die Option zum Ignorieren setzt
in glob.

Gedanken? Ich kann ganz schnell eine PR dafür machen, wenn Sie möchten.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/mochajs/mocha/issues/1577.

Ich könnte (und habe es in der Vergangenheit getan), aber ich würde das jetzt lieber nicht mehr tun müssen, da mir klar geworden ist, dass Glob Ignore genau dort ist.

Es sollte ziemlich einfach sein, ein Befehlszeilenargument hinzuzufügen, um die Option zum Ignorieren des Globs festzulegen. Ich wollte nur zuerst Gedanken bekommen und ein wenig diskutieren.

Irgendwelche Einwände gegen mich, eine PR dafür zu erstellen?

Ich brauchte das auch nur und war überrascht zu sehen, dass Mokka es noch nicht hatte. Ich denke, es wäre eine großartige Ergänzung. Wir haben eine "testApp" in unserem Testordner, die wir speziell zum Testen verwenden. Wir möchten nicht, dass Mokka versucht, Tests in diesem Ordner auszuführen. Es wäre schön, wenn Sie unserer Datei mocha.opts nur einen Ausschluss hinzufügen könnten, um diesen bestimmten Pfad auszuschließen, anstatt alle anderen Test-Unterordner, die wir haben, explizit einschließen zu müssen.

Obwohl wir die testApp herausschieben könnten, passt sie wirklich nirgendwo anders in das Repo und hat einen relativen Pfad zu bestimmten Dateien im Testordner.

Dies wäre meiner Meinung nach eine schöne Ergänzung. Sicher nicht kritisch, aber hilfreich.

@KylePDavis @toddbluhm

Wenn ich das brauchte, würde ich es wahrscheinlich nur tun

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

Ich bin also nicht wirklich begeistert von der Idee. Ich bin ein bisschen auf dem Zaun über die Existenz der recursive -Flagge, da das gleiche mit einem Shell-Befehl erreicht werden kann: Makefile , Gruntfile.js , gulpfile.js usw. usw.

Ich denke, @boneskull macht einen guten Punkt - dies ist bereits auf verschiedene Arten erreichbar. Und das schließt nicht die Tatsache ein, dass Sie Ihre Verzeichnisse strukturieren können, um dies insgesamt zu vermeiden. Zum Beispiel bei dieser Struktur:

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

4 directories, 0 files

Sie aktualisieren einfach Ihre package.json, sodass Sie einfach npm test ausführen können

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

Oder mit einer Struktur wie der folgenden:

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

2 directories, 2 files

Sie können Spezifikationen auf ähnliche Weise wie im Beispiel von @boneskull ausführen (dies führt nur Dateien aus, die Spec ).

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

Edit: Behoben :)

@danielstjules Ich denke, das wird tatsächlich jedes Verzeichnis mit Spec im Namen treffen. Vielleicht möchten Sie -name '*.spec.js'

Ja, du hast recht! Gehirnfurz. Vielen Dank für den Hinweis.

Befehl für das Beispiel behoben:

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

Ich denke, es gibt immer noch einen gültigen Anwendungsfall für diese Funktion: Ich neige dazu, meine Dateien nach Funktionen zu gruppieren, sodass sich jede Testdatei neben den Dateien befindet, die die Logik enthalten, die sie testen. Das Benennen von Testdateien funktioniert konsistent mit dem Argument file oder der Option grep aber ich möchte Dinge wie node_modules explizit ignorieren.

Für alle, die suchen - Schluck-Mokka kann dies erreichen, ich hasse es einfach, gulp wo ich nicht muss.

Ich würde mir gerne einen Moment Zeit nehmen und +1 diese Idee. Im Gegensatz zu typischen JavaScript-Projekten verfolge ich gerne die Art und Weise, wie GO Unit-Tests durchführt, und füge neben jeder einzelnen Datei, die getestet wird, eine Spezifikationsdatei ein. Beispielsweise könnte ein Verzeichnis in einem meiner Projekte wie folgt aussehen:

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

Ich finde, diese Art von Organisation macht es viel einfacher, Tests zu finden, als in einem einzigen Verzeichnis von Testdateien zu graben. Sie erwarten immer, dass der Test direkt neben der zu testenden Datei steht und mein Build-Skript alle .spec.js-Dateien in der bereitgestellten Version ausgibt.

Aufgrund meines nicht standardmäßigen Layouts möchte ich in der Lage sein, alle Komponententests mit allen meinen Ordnern außer dem Verzeichnis node_modules auszuführen.

Ich habe momentan keine Windows-Box in meiner Nähe, bin mir aber nicht sicher, ob diese Suchsyntax unter Windows funktionieren würde oder nicht. Eine Ausschlussoption wäre meiner Meinung nach ohnehin weitaus intuitiver. Außerdem enthalten fast alle Unit-Test-Frameworks eine Möglichkeit, Dateien zu ignorieren, sodass Parität hilfreich wäre.

Hallo, alle meine Tests unterstützen das Format *.test.js . Sie befinden sich alle im Verzeichnis tests . Derzeit habe ich einige Tests, die ich ausschließen möchte, und behalte weiterhin den Standardpfad für Mokka bei, der ./test/**/*.js . Wie mache ich das?

Das Erstellen von zwei separaten Verzeichnissen funktioniert hier nicht, und Sie müssen zustimmen, dass das Verschieben von Tests zwischen Verzeichnissen in VCS viel Rauschen verursachen würde.

@calebthebrewer Zum Glück

+1 @calebthebrewer

Angular 2.0 und Polymer haben mich im Komponentenmodus, daher stimme ich @KrisSiegel zu. Wenn Sie Ihren gesamten Code in Bundles aufbewahren, bleibt eine saubere, modulare und einfach zu wartende Dateihierarchie erhalten.

Gibt es ein vorhersehbares Problem beim Laden der Tests mit der Versprechungsbibliothek q auf folgende Weise:

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

Auf diese Weise können Sie Ihre Dateien von überall importieren und haben nur eine Testdatei in test/ .

Sie können das Versprechen innerhalb des letzten Testblocks auflösen und jeden Test so abschließen

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

Es scheint ziemlich gut zu funktionieren, es sei denn, es gibt etwas, über das ich nicht nachdenke.

Wir sollten den Glob immer noch ignorieren. Die Verwendung von Bash-Befehlen ist keine plattformübergreifende Lösung.

+1

Ich möchte wirklich node_modules . Exclusion scheint ein ziemlich praktischer Begleiter von recursive .

@godspeedelbow Warum sollte dieses bestimmte Verzeichnis explizit ignoriert werden müssen? Normalerweise höre ich nicht, dass sich node_modules in einem Testverzeichnis befindet.

FWIW, ich könnte das auch wirklich gebrauchen. Ich habe ein paar Projekte, bei denen die Tests weitaus größer sind als die Bibliothek selbst, und dies würde es mir ermöglichen, sie besser zu organisieren (Geräte gehören meiner Meinung nach in ein Testverzeichnis).

Das Ignorieren von node_modules wird wichtig, wenn Sie entweder etwas Unerwartetes tun (wie ich, wo ich Spezifikationsdateien neben der zu testenden Datei aufbewahre, anstatt sie in einem einzelnen Ordner zu speichern, weg von dem zu testenden Code) oder wenn Sie möchten Unit-Tests für ein Hauptprojekt und einige der enthaltenen Projekte ausführen (möglicherweise handelt es sich um interne Bibliotheken, nicht im npm-Repo, das Sie testen möchten), aber Sie möchten die Unit-Tests nicht in ihren eigenen Abhängigkeiten ausführen .

Dieses Problem gibt es schon seit fast einem ganzen Jahr, daher habe ich nicht viel Hoffnung, dass es umgesetzt wird. Meiner Meinung nach ist die Implementierung wichtig, da für die Problemumgehungen entweder plattformspezifische Terminalbefehle erforderlich sind oder Sie explizit Muster für jedes Verzeichnis angeben, das Sie testen möchten (daher müssen dem Testskript zusätzliche Verzeichnisse hinzugefügt werden). Ich würde es teilen und es einfach selbst tun, aber die Hacky-Methode zum Festlegen jedes Verzeichnisses und eines Musters ist einfach einfacher, als die Zeit zu finden, um es in Mokka zu implementieren.

@KrisSiegel Du src/**/*.js und src/**/*.spec.js . Ich sehe das häufiger in Go- und Rust-Projekten als im Projektstamm. Tatsächlich ist letzteres relativ ungewöhnlich.

Obwohl ich denke, dass sie nur darauf warten, dass sich jemand die Zeit nimmt, es selbst zu tun. Es scheint kein schwieriger Patch zu sein (es sei denn, diese Logik ist ein Spaghetti-Code-State-Machine-Chaos).

Ich bin nicht so motiviert, dies persönlich zu tun, weil ich tatsächlich an einem eigenen Test-Framework arbeite, das eine vollständige Alternative zu Mokka, Jasmin, Klebeband usw. darstellen soll, obwohl es im Kern einfacher und leistungsfähiger ist. Es ist jedoch noch zu viel Arbeit für Geldautomatenprojekte.

Ich benutze Mocha, um das Framework effektiv zu booten. Ich habe Chai anfangs für die Assertions verwendet, bis ich diese stabilisiert habe (sie sind jetzt praktisch API-gesperrt, da ich die Assertions des Frameworks verwende, um sich selbst zu testen).

Ja, das ist eine Problemumgehung. Ich sehe nur nicht viele JavaScript-Projekte, die so strukturiert sind, obwohl das Gleiche auch für das Pairing der Spezifikations- und Quelldatei gilt. Ich verwende dieses Muster im Wesentlichen, aber wenn ich in Projekte komme, die mit ihren eigenen benutzerdefinierten Build-Systemen bereits ziemlich groß sind, ist es nicht immer einfach, es zu ändern.

Ausschließen ist ein ziemlich grundlegendes Muster, das viele Dienstprogramme haben. Ich denke Mokka braucht es :). Obwohl ich den Eindruck habe, dass dieses Problem aufgrund plattformspezifischer Problemumgehungen geschlossen wurde, war es nicht erwünscht, statt auf einen Patch zu warten. Wenn dies etwas ist, was die Mokka-Leute tatsächlich wollen würden, dann könnte ich, wenn es nicht in ein paar Wochen fertig ist, sicherlich einen Patch herauskurbeln.

@KrisSiegel Ich bin mir ziemlich sicher, dass wenn jemand tatsächlich einen Patch Plattform abhängig ist . Und ich sehe nicht sehr viele Windows-Benutzer, die bereit sind, GNU find zu installieren, nur um ein paar Tests durchzuführen.

Es kann geschlossen werden, aber eine ähnliche Situation passiert bereits bei Node mit Web-Workern , obwohl die Implementierung von Node leicht abweichen wird ( geschlossenes Problem , PR in Bearbeitung ).

+1 für das, was es wert ist. Für ein von mir erstelltes Projekt ist kein Ordner app oder src erforderlich, sondern eine variable Anzahl benannter Ordner mit unterschiedlichen Schnittstellenimplementierungen. Ich möchte auch, dass meine Tests für jede Schnittstelle gebündelt bleiben und nicht gezwungen werden, einen einzelnen Ordner für Tests zu verwenden.

Es wäre ideal, Dateien angeben zu können, die mit einem .mochaignore oder einer anderen Option ignoriert werden sollen, da ich sie auf diese Weise einfach mit einem **/*.spec.js glob ausführen könnte und mir keine Sorgen machen könnte, dass sie Tests aus dem node_modules könnten

Fast alle anderen Build-Tools erlauben dies. Wir haben .npmignore , .gitignore , .jshintignore und jscs bietet eine Option zum Konfigurieren über .jscsrc . Es wäre nützlich, wenn Mocha dies ebenfalls unterstützen würde, da immer mehr Menschen sich der Organisation von Komponenten- / Feature-Dateien und Ordnern zuwenden, weg vom Ansatz der Sockenschublade.

@isiahmeadows Wie andere bereits erwähnt, habe ich eine Ordnerstruktur, die ich nicht einfach ändern kann. Daher befinden sich services/ , routes/ usw. genau wie node_modules im Stammverzeichnis des Projekts node_modules auszuschließen, damit nur meine eigenen Tests getestet werden.

Ich würde es gerne selbst in Mokka implementieren, wenn ich gewusst hätte, wo ich anfangen soll :)

@godspeedelbow @adambuczynski Eine vorübergehende Lösung :)

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

Hallo @danielstjules danke! Versuchte es, aber aus irgendeinem Grund findet find . -name '*.spec.js' ! -ipath '*node_modules*' nur eine Testdatei.

Haben Sie '*.spec.js' aktualisiert, um dem Muster zu entsprechen, dem Ihre Tests folgen? Zum Abgleichen von _all_ js-Dateien würden Sie beispielsweise Folgendes verwenden:

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

@danielstjules Prost , aber das würde unter Windows meiner Meinung nach nicht funktionieren, und obwohl es für diese App kein Problem ist, einzubauen .

In der Zwischenzeit habe ich versucht, den App-Code und die Tests in einen Unterordner von app damit ich diesen Ordner für die Tests als Ziel festlegen kann und mich nicht um node_modules oder andere Ordner kümmern muss.

@danielstjules Ja, alle Testdateien haben das Format *.spec.js . Aus irgendeinem Grund hat es früher nicht funktioniert, aber jetzt, wenn es ohne Probleme funktioniert. Vielen Dank für diese * NIX-Problemumgehung.

Ich möchte, dass dies für einen kommenden Major getan wird. Die gezielte Unterstützung von .mochaignore erscheint mir vernünftig

@ Boneskull Danke, das wäre toll.

Würden Sie für die nächste Hauptversion auch die Implementierung eines "Standard" .mocharc für die Übergabe von Optionen in Betracht ziehen, die im Stammverzeichnis des Projekts abgelegt werden können, anstatt ein mocha.opts im Ordner test ?

Das würde die Konfiguration von Mocha viel einfacher machen und der Art und Weise entsprechen, wie es mit anderen Tools da draußen gemacht wird. Außerdem würde es uns nicht zwingen, einen test -Ordner nur für die mocha.opts . (Wir stellen alle unsere Tests neben die Module, die sie testen).

@adambuczynski absolut. Ich bin kein Fan von mocha.opts

@adambuczynski toller Kommentar. Ich stimme zu, ich hätte auch gerne eine Standard-Optionsdatei .mocharc, ich verwende auch kein Testverzeichnis mehr, da es so schön ist, Tests neben dem Code zu halten.

+1, ich denke Ausschluss ist wirklich nötig.

@adambuczynski @boneskull In der Dokumentation wird angegeben, dass Sie --opts , um einen Pfad zu Ihrer opts-Datei anzugeben, obwohl keine Beispiele angegeben sind. Ich verwende dies in meinem aktuellen Projekt und kann bestätigen, dass es als mocha --opts .mocharc funktioniert

Danke @GRUBES. Am Ende habe ich weiterhin den Ordner test weil ich dort auch meine Test-Setup-Helfer abgelegt habe, aber es ist gut zu wissen, dass dies möglich ist.

Glob hat eine Ignorieroption, daher sollte es keine große Sache sein, nur eine Ausschlussoption hinzuzufügen und an glob ignore weiterzuleiten.

Ignorieren Fügen Sie ein Muster oder ein Array von Glob-Mustern hinzu, um Übereinstimmungen auszuschließen. Hinweis: Ignoriermuster befinden sich unabhängig von anderen Einstellungen immer im Punkt: True- Modus.

Ich bin mir nicht sicher, warum dies länger als ein Jahr dauert. :-)

@ inf3rno Übrigens , dies wäre wahrscheinlich viel früher gelöst worden, wenn sich jemand tatsächlich

@isiahmeadows Ye, aber das werde ich nicht sein. : D.

Braucht das also noch eine PR? Ich würde dies gerne hinzufügen, da ich lieber die Colocation der Testdatei anstelle der mehreren Verzeichnisse für test und test-integration

2036, das im Grunde genommen nur eine Datei und keine Befehlszeilenoption ist, hat die PR # 2173

Vielleicht ist es schön, eine Option wie --exclude hinzuzufügen.

Oder unterstützen Sie so etwas wie mocha test/*.js !test/_*.js

Herausgefundener Globus: mocha "./{,!(node_modules)/**/}*.test.js" , um alle * .test.js-Dateien außer in node_modules abzurufen, und mocha "./test/**/!(notThisOne).js" , um alles im Testordner und in den Unterordnern außer notThisOne.js abzurufen

Siehe auch:
https://github.com/isaacs/node-glob#glob -primer
https://github.com/isaacs/node-glob/issues/62

@ScottFreeCode

Beim Laufen im Terminal bekomme ich

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

Sollte dieser Charakter entkommen?

@mdumouchel Verwenden Sie einfache Anführungszeichen. Ansonsten ja.

@isiahmeadows

Immer noch Fehler

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'

Am Ende habe ich nur den Befehl find verwendet

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

@mdumouchel Wenn Sie Version 2.x verwenden (dh was auf npm läuft), wird es sowieso nicht funktionieren. Die Unterstützung beginnt in 3.x, IIRC.

Das ist komisch, ich dachte, ich habe es in Bash versucht und konnte doppelte Anführungszeichen verwenden. Kennt jemand eine Syntax / Escape, die sowohl unter Windows als auch in Bash funktioniert?

Ich bin mir auch ziemlich sicher, dass der Fehler "Pfad kann nicht aufgelöst werden" bedeutet, dass der Pfad nicht mit Dateien in Ihrem Projekt übereinstimmt. Der Pfad, den ich angegeben habe, hat in der aktuellen Version funktioniert, als ich Testdateien mit Namen mit der Endung ".test.js" neben den entsprechenden Quelldateien hatte, es sei denn, ich habe es vermasselt, sie von meinem Test in den Problemkommentar zu kopieren ...

Siehe # 2173

Eslint macht einen großartigen Job und ignoriert Dateien mit --ignore-path (und .eslintignore ).
Siehe: http://eslint.org/docs/user-guide/command-line-interface#ignoring -files

Ähnliches für Mokka wäre fantastisch: two_hearts:

Meine Problemumgehung:

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

Meine Dateistruktur

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

Problem: Mokka gibt mir Error: cannot resolve path (or pattern) wenn einer der beiden Pfade nicht mit etwas übereinstimmt ..: enttäuscht_relieved:

OK, also gebe ich nach. Dies ist einfach nicht benutzerfreundlich.

Ich denke, wir sollten Folgendes tun:

1. Unterstützt --exclude <glob-or-path>
2. Unterstützt mehrere Instanzen von --exclude
3. Kombinieren Sie alle --exclude -Optionen mit allen Nicht-Optionsargumenten in einer einzigen Liste (im Grunde das, was globby tut).
4. Laden Sie diese Dateien

Derzeit unterstützen wir _n_ Nicht-Optionsargumente, die alle Globs sein können, aber dies ist nur _additiv_; Das funktioniert nicht so, wie Sie es erwarten würden:

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

Das Obige sollte also funktionieren, und --exclude ist wirklich nur Zucker für ! .

Darüber hinaus klingt die Unterstützung von .mochaignore (# 2036) gut, ist jedoch ein separates Problem. Es sollte ein 3p-Modul geben, das wir verwenden können, um ein .gitignore -ähnliches Verhalten zu erzielen. Ich bin sicher, dass alles, was ESLint tut, für unsere Zwecke gut genug ist.

... und wenn es nicht klar ist, verwenden Sie keine nicht zitierten Globs in der Befehlszeile. siehe # 2355

Überraschenderweise gibt es immer noch keine Option wie --ignore-path . Abgesehen davon, dass alle Tests in einem Ordner tests abgelegt werden, gibt es keinen Grund, warum wir Tests nicht zusammen mit Modulen platzieren können.

+1
Das Ignorieren von Dateien oder Verzeichnissen nach Muster ist eine sehr nützliche Funktion

@isiahmeadows

Sie können immer src / / .js und src / /.spec.js ausführen

Nein, das konnten Sie nicht - der **/* -Musterabgleich ist fehlerhaft und funktioniert nicht rekursiv.

EDIT: @ScottFreeCode hat die Antwort unten

Der **/* -Musterabgleich ist fehlerhaft und funktioniert nicht rekursiv.

Sind Ihre Pfade zitiert ?

+1

Wie unter https://github.com/zinserjan/mocha-webpack/issues/124 beschrieben :

In src/ befindet sich eine Datei namens server.ts die einen Express-Server auslöst und im Hintergrund ausgeführt wird. Der Server ist normalerweise aktiv, wenn die Abdeckung ausgeführt wird, sodass der Port bereits verwendet wird.

Wir wollen also nicht, dass dies und nur diese Datei ausgeschlossen wird.

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

Ich bin der Meinung, dass Mokka ignoriert werden muss, denn auch nach all dieser Zeit müssen die Betreuer noch überzeugen.

Mokka ist Kanon. Warum nicht die Messlatte für die plattformübergreifenden Funktionen des Testframeworks höher legen, die alle anderen Testframeworks anstreben? Wir sollten aufhören zu streben, alles Bash zu überlassen. Es ist schon 2017.

Ich werde auch darauf hinweisen, dass Windows-Benutzer nichts haben, was Bashs !(glob) (was eigentlich ein Bash-Ismus ist, nicht einmal der POSIX-Standard).

Es sollte keine Bash-Abhängigkeit in Mochas Globbing-Ist-Zustand geben, da es über das Glob JS-Modul verarbeitet wird. (Hinweis: Das Zitieren der Pfade kann erforderlich sein, um zu vermeiden, dass die Shell Globs anders verarbeitet als Mocha, z. B. ** ohne die Globstar-Erweiterung oder was auch immer das Besondere daran ist.)

@ScottFreeCode Verwenden Sie extglob: true wenn Sie glob verwenden? Wenn dies der Fall ist, kann dies mit dieser Syntax als Problemumgehung geschlossen werden (da glob / minimatch dies mit aktivierter Option unterstützt).

Es sieht so aus, als würden wir nur den Weg zum Glob passieren . Ich bin mir ziemlich sicher, dass ich irgendwann eine Negation durch ein Glob-Muster bekommen habe, aber das könnte eine ältere Version des Moduls gewesen sein? In jedem Fall haben wir Tests für das Doppelsternverhalten. Wenn also jemand Tests einreichen möchte, um zu bestätigen, dass einige Negationsmuster auch funktionieren (oder wenn jemand Fehler in den bereits vorhandenen Globbing-Tests findet), wäre das großartig .

Es ist jedoch ein klarer Vorteil, eine explizite Option ignore / exclude . Eigentlich mehrere Vorteile:

• weniger dunkel
• Es ist einfacher, Konflikte mit Sonderzeichen und Anführungszeichen für verschiedene Betriebssysteme zu vermeiden
• Eine Einschlussliste ohne Ausschlussliste ist in vielen Fällen einfacher als eine Einschlussliste mit negierten Teilen

Ich wollte nur klarstellen, dass der Status Quo nicht auf einer bestimmten Shell beruhen soll. ; ^)

Eine Einschlussliste ohne Ausschlussliste ist in vielen Fällen einfacher als eine Einschlussliste mit negierten Teilen

Stimmt, und das hatte ich fast vergessen 😄

Jeder, der zu diesem Thema kommt:

Die Problemumgehung besteht nun darin, Globs zu verwenden, da dies unterstützt werden sollte. Wenn jemand dieses spezielle Verhalten wünscht, senden Sie bitte eine PR.

Funktioniert die Option --exclude ?
Kann es nicht in Dokumenten finden .

@ sepo-one Ich habe PR geöffnet, um das Dokument zu aktualisieren.
Sie können alle verfügbaren Optionen unter mocha -h .

Ja, ich habe eine alte Version von Mokka verwendet. Upgraded und --exclude Option ist da.
Die Dokumente sollten sowieso aktualisiert werden, denke ich.

Danke @outsideris