Sinon: Wie können wir das Ablehnen beim Erstellen eines neuen Fehlerobjekts überschreiben?

Erstellt am 1. Feb. 2018 · 6Kommentare · Quelle: sinonjs/sinon

https://github.com/sinonjs/sinon/blob/4310343393b16b92b56526ab4614da4eb2886efa/lib/sinon/default-behaviors.js#L176

Ich verwalte einen Code, der Zeichenfolgen ablehnt, und dies führt beim Testen zu Problemen. Meine Bluebird-Fänge verhalten sich nicht richtig.

bluebird.rejects('Something')
    .catch(e => e === 'Something' /* true */, () => console.log(typeof e) /*string*/)
    .catch(() => console.log('should not be here'));

Bei Verwendung von sinon.stub().usingPromise('bluebird').rejects('Something'); jedoch ein Fehlerobjekt mit dem Namen Something erstellt. Überhaupt nicht erwartet.

Bevor jemand sagt, dass wir nur native Versprechen unterstützen, wollen wir untersuchen, was sie tun!

Promise.reject('Something')
     .catch(e => {
        console.log(e === 'Something'); // true
        console.log(typeof e); // string
    });

Hmmm, sie erstellen keine Fehlerklasse, sie werfen nur die Ausnahme, die sie gegeben hat, wie einen Wurf.

try { 
    throw 'Something'; 
} catch (e) { 
    console.log(e === 'Something');  // true
    console.log(typeof e); // string
}

Bug Help wanted pinned

Quelle

JemiloII

Hilfreichster Kommentar

Stack-Trace-Nützlichkeit und Diskussionen darüber, ob man Fehlerobjekte beiseite legen sollte, stimme ich im Allgemeinen zu

const example = sinon.stub().rejects(something);

sollte sich genauso verhalten wie

const example = () => Promise.reject(something);

Derzeit ist dies nicht der Fall, wenn something eine Zeichenfolge ist. Ich würde sagen, das aktuelle Verhalten ist ein Fehler.

mantoni am 8. Sept. 2020

👍4

Alle 6 Kommentare

Bevor jemand sagt, dass wir nur native Versprechen unterstützen, wollen wir untersuchen, was sie tun!

Das ist ein Strohmann-Trugschluss . Sie wissen genau, dass wir Versprechen-Bibliotheken unterstützen, wie Sie sie in Ihrem Beispiel verwenden.

Die Sinon-Betreuer wissen genau, wie JavaScript-Versprechen funktionieren, einschließlich der Tatsache, dass Promise.reject() alles weitergibt, was Sie an ihn weitergeben.

Ich verwalte einen Code, der Zeichenfolgen ablehnt

Meiner Meinung nach ist das Ablehnen von Versprechungen mit String anstelle von Error ein schlechter Dienst für Future Developer, der debuggen muss, was wir heute schreiben. Strings sind für das Debuggen nicht sehr nützlich, da sie keine Stack-Traces erfassen. Error dagegen schon. Daher denke ich, dass rejects() Verhalten wünschenswert ist, da es einfach ist, den Debugger zu verwenden, um schnell herauszufinden, was schief gelaufen ist.

Es scheint, dass Sie nicht einverstanden sind, aber die einzige Aussage, die Sie gemacht haben, ist, dass Sinon Ihre Erwartungen nicht erfüllt. Wenn Sie der Meinung sind, dass das Standardverhalten geändert werden sollte, geben Sie bitte Argumente dafür an, warum die Änderung möglicherweise viele Benutzer betrifft.

Wenn es solide Argumente für die Änderung des Standardverhaltens gibt, kann ich mir nicht vorstellen, dass einer der Betreuer von Sinon eine Pull-Anfrage zur Änderung ablehnen würde.

mroderick am 11. Feb. 2018

👍1

Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivitäten gab. Es wird geschlossen, wenn keine weitere Aktivität stattfindet. Vielen Dank für Ihre Beiträge.

stale[bot] am 12. Apr. 2018

Ich würde sagen, es könnte unterschiedliche Meinungen darüber geben, ob ein Stack-Trace in bestimmten Szenarien tatsächlich nützlich ist oder nicht. In meiner speziellen Situation ist mir die Stapelverfolgung eigentlich egal, ich kümmere mich nur um die Fehlermeldung und übergebe sie dann an eine andere Stelle. Daher habe ich Code geschrieben, um sowohl Ablehnungsgründe für Zeichenfolgen als auch für Fehler zu behandeln. Da sinon jedoch den String -> Error-Zwang für mich ausführt, kann ich den Zweig meines Codes, der Strings verarbeitet, nicht testen. Als solches kann ich keine vollständige Abdeckung erhalten

dtom90 am 8. Sept. 2020

Stack-Trace-Nützlichkeit und Diskussionen darüber, ob man Fehlerobjekte beiseite legen sollte, stimme ich im Allgemeinen zu

const example = sinon.stub().rejects(something);

sollte sich genauso verhalten wie

const example = () => Promise.reject(something);

Derzeit ist dies nicht der Fall, wenn something eine Zeichenfolge ist. Ich würde sagen, das aktuelle Verhalten ist ein Fehler.

mantoni am 8. Sept. 2020

👍4

Genau.

JemiloII am 17. Sept. 2020

Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivitäten gab. Es wird geschlossen, wenn keine weitere Aktivität stattfindet. Vielen Dank für Ihre Beiträge.

stale[bot] am 25. Dez. 2020

War diese Seite hilfreich?

0 / 5 - 0 Bewertungen

Sinon: Wie können wir das Ablehnen beim Erstellen eines neuen Fehlerobjekts überschreiben?

Hilfreichster Kommentar

Alle 6 Kommentare

Verwandte Themen