gewusst wie: übergeben Sie einen test mit expect.js async-done() zu nehmen, ein Fehler?

Nicht async. Die callback-Funktion ist nur für dich da zu informieren, mocha, dass Sie das testen von asynchronen code und so mocha sollte nicht führen Sie den nächsten test, bis Sie den Anruf der callback-Funktion. Dies ist ein Beispiel für die Verwendung der callback-Funktion:

it('works',function(done){
    setTimeout(function(){
        //happens 0.5 seconds later:
        expect(1).to.be(1);
        done(); //this tells mocha to run the next test
    },500);
});

Auch, mocha behandelt nicht jede form von Ausnahmen, async oder sonst. Es Blätter, die bis auf eine Ausnahme-Bibliothek Ihrer Wahl. In deinem Fall bist du mit expect.js? Wenn dem so ist, erwarten Griffe erwartete Fehler über die throwException - Methode (auch genannt throwError):

it('throws an error',function(done){
    expect(function(){
        throw new Error('expected error');
    }).to.throwError(/expected error/);
});

Nun, allgemein async-code in node.js nicht werfen Fehler. Sie passieren Fehler, die an den callback als Parameter statt. So Griff async Fehler Sie können einfach überprüfen Sie das err-Objekt:

//using readFile as an example of async code to be tested:
it('returns an error',function(done){
    fs.readFile(filename, function (err, data) {
        expect(err).to.be.an(Error);
        done(); //tell mocha to run next test
    })
});

So verwenden to.throwError() wenn Sie überprüft haben, synchrone Fehler und to.be.an(Error) wenn Sie überprüft haben, async Fehler.

Zusätzliche Hinweise:

Das erste mal ich dieses sah, war ich etwas verblüfft. Wie kann mocha wissen, dass der test synchron oder asynchron, wenn der einzige Unterschied ist noch, ob die Funktion übergeben Sie es akzeptiert ein argument oder nicht? Im Falle, du bist wie ich und sind am Kopf kratzen, Frage mich, wie habe ich gelernt, dass alle Funktionen in javascript haben eine length Eigenschaft, die beschreibt, wie viele Argumente er akzeptiert in seiner Erklärung. Nein, nicht die arguments.length Sache, die Funktion, die eigenen length. Zum Beispiel:

function howManyArguments (fn) {
    console.log(fn.length);
}

function a () {}
function b (x) {}
function c (x,y,z) {}

howManyArguments(a); //logs 0
howManyArguments(b); //logs 1
howManyArguments(c); //logs 3
howManyArguments(howManyArguments); //logs 1
howManyArguments(function(x,y){}); //logs 2

Also Mokka im Grunde prüft die Funktion Länge, um zu bestimmen, Wetter zu behandeln, als eine synchrone Funktion oder asynchrone Funktion und unterbricht die Ausführung warten für die done() Rückruf wenn es asynchron.

Noch mehr zusätzliche Hinweise:

Mocha, wie die meisten anderen js unit-test-Runner und Bibliotheken, Arbeit durch abfangen von Fehlern. So rechnet es sich, Funktionen wie expect(foo).to.be.an.integer() einen Fehler auslösen, wenn die assertion fehlschlägt. Das ist, wie Mokka kommuniziert mit assertion-Bibliotheken wie erwartet oder chai.

Nun, wie ich oben erwähnte, ist eine gemeinsame Redewendung in Knoten ist, dass async-Funktionen werfen Sie nicht die Fehler, sondern übergibt ein Fehler-Objekt als erstes argument. Wenn dies geschieht, Mokka kann nicht erkennen, die Fehler und so nicht erkennen kann, einen fehlerhaften test. Der work-around ist, dass wenn du an das error-Objekt aus, das async-code der callback-Funktion, die es zu behandeln, wird es das gleiche wie ein Fehler geworfen.

Also, eines meiner Beispiele oben:

it('executes without errors',function(done){
    fs.readFile(filename, function (err, data) {
        done(err); //if err is undefined or null mocha will treat
                   //it as a pass but if err is an error object
                   //mocha treats it as a fail.
    })
});

Oder einfach:

it('executes without errors',function(done){
    fs.readFile(filename,done);
});    

Streng genommen, ist diese Funktion ein wenig überflüssig, wenn verwendet mit Bibliotheken wie expect.js die können Sie manuell überprüfen Sie die error-Objekt zurückgegeben, aber es ist nützlich, wenn Sie Ihre Behauptung Bibliothek kann nicht überprüfen Sie das error-Objekt (oder, wenn Sie nicht wirklich über das Ergebnis der asynchronen Funktion, sondern wollen einfach nur, um zu wissen, dass keine Fehler geworfen).