Sinon: Verbessern Sie Dokumente für Fälschungen

Fälschungen brauchen definitiv bessere Dokumente. Vielleicht etwas, das im vorgeschlagenen (noch unentschlossenen, @mroderick?) Oktober-Hackathon angesprochen werden soll?

@ fatso83 Ich würde das gerne mal

Würde ich die Datei https://github.com/sinonjs/sinon/blob/master/docs/release-source/release/fakes.md aktualisieren?

Ist es auch der Umfang dieser Ausgabe, zu definieren, welche Funktionen für ein Scheinobjekt verfügbar sind, möglicherweise eine Verknüpfung mit der Spionage- und Stub-Dokumentation?

@ Peterjgrainger Das ist großartig! Der Umfang und dieser Ansatz scheinen vernünftig ...

Wenn man sich die Code-Fälschungen ansieht, scheint es dieselbe API wie bei einem Spion zu geben und nichts von einem Stub.

Schlagen Sie vor, die Dokumente zu aktualisieren, um den Verweis auf Stubs zu entfernen, da dies etwas irreführend ist, und hinzuzufügen, dass die API von Fälschungen mit der eines Spions identisch ist

Schrei 😮 wenn das nicht richtig aussieht.

@peterjgrainger Danke, dass spy , und stub zB fakes.throws() ist dasselbe wie stub().throws()

@ mshaaban0 danke für die Eingabe. Ich werde genauer hinsehen

@ fatso83 @ mshaaban0 Ich glaube, ich habe den Umfang falsch verstanden.

Ich dachte, dieses Ticket deckt die Dokumentation der gefälschten Funktion ab, z

var fake = sinon.fake();

nicht direkt auf der Fälschung selbst dh

sinon.fake

Soweit ich sehen kann, gibt sinon.fake() ein spy Ich denke, dieser Teil der Dokumentation muss geklärt werden, da der Reporter eher nach Dokumentation zum Objekt als nach den statischen Funktionen fragt.

Ich bin zu diesem Schluss gekommen, weil es den Anschein hat, dass das gefälschte Objekt die Eigenschaft called wie es ein Spion tut (kann dies nur in der Spionagedokumentation dokumentiert finden)

@itmayziii scheint sich eher auf sinon.fake() als auf sinon.fake zu beziehen

Ich glaube ich verstehe was ich jetzt tun soll. Ändern Sie die aktuelle Dokumentation, um festzustellen, welche statischen Funktionen von einem Spion und welche von einem Stub inspiriert sind, und ändern Sie den Wortlaut merged , um den Methodenmix besser zu beschreiben, und versuchen Sie herauszufinden, wie Sie zwischen sinon.fake und sinon.fake()

Sie sind nicht der einzige, der den Umfang falsch versteht. Ich bin froh, dass du es für uns geklärt hast 😄

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.

Ich glaube ich verstehe was ich jetzt tun soll. Ändern Sie die aktuelle Dokumentation, um zu sagen, welche statischen Funktionen von einem Spion und welche von einem Stub inspiriert sind, und ändern Sie den zusammengeführten Wortlaut, um den Methodenmix besser zu beschreiben. Versuchen Sie auch herauszufinden, wie Sie zwischen sinon.fake und sinon.fake unterscheiden können ( )

Was ist in dieser Ausgabe zu tun? Wenn jemand es klarer macht, möchte ich einen Beitrag leisten.

Da es einen Abschnitt namens Instance properties , müssen meines Erachtens nur Methoden einer gefälschten Funktion erklärt werden. Wenn es für eine gefälschte Funktion keine anderen Methoden als Spionagemethoden gibt, gibt es meines Erachtens keinen Grund, die aktuellen Dokumente zu überarbeiten.

Danke 😊

@srknzl TBH, ich erinnere mich nicht so gut, aber dies sind einige Punkte, die verbessert werden könnten:

• Stellen Sie sicher, dass die Liste der statischen Factory-Methoden für sinon.fake vollständig ist
• Konvertieren und / oder Hinzufügen einiger ausführbarer Runkit-Beispiele (sehr einfach, aber etwas zeitaufwändig)
• Aktualisieren Sie den Link in den Instanzeigenschaften, um auf denselben Abschnitt in Spies zu verweisen.
• Geben Sie an, dass die aufgelisteten Requisiten nur eine von vielen aus der Spionagedokumentation sind und dass Sie sich für die vollständige Liste darauf beziehen können
• Klären Sie den Wortlaut so, dass klar wird, dass 1. die Fakes-API eine Alternative zur Stubs and Spies-API ist, die alle diese Verwendungen vollständig ersetzen kann. 2. Es soll einfacher zu verwenden, zu warten und hat eine viel kleinere API-Oberfläche und vermeidet viele Fehler durch quazi-unveränderliche Fake-Instanzen (das Verhalten kann nach der Erstellung nicht geändert werden (im Gegensatz zu Stubs), aber sie haben den internen Status, dass Änderungen bei Verwendung, wie callCount und andere Statistiken) 3. Eine gefälschte Instanz hat die API eines Spions (_ist ein_ gefälschter Spion, @mroderick?)

Die Fakes-API ist eine Alternative zur Stubs and Spies-API, die alle diese Verwendungen vollständig ersetzen kann

Obwohl dies zutrifft, denke ich, dass es einfacher ist, einen Spion anstelle eines Fake + Replace-Anrufs zu verwenden. Kann man etwas dagegen tun?

const foo = {bar: () => {}};
const aSpy = sinon.spy(foo, 'bar');
foo.bar();

console.log(aSpy.called); // true

vs.

const foo = {bar: () => {}};
const barFake = sinon.fake(foo.bar);
sinon.replace(foo, 'bar', barFake);
foo.bar();

console.log(barFake.called); // true

Wenn es so einfach wäre wie Spione, wären Fälschungen die einzigen, die ich verwenden werde.

Bearbeiten:

Ich habe herausgefunden, dass ich das kann:

const foo = {bar: () => {}};
sinon.replace(foo, 'bar', sinon.fake(foo.bar));
foo.bar();
console.log(foo.bar.called); // true

Es könnte sich auch lohnen, diese Verwendung zu dokumentieren.

@srknzl Ich bin nicht sicher, ob der Ersetzungsaufruf etwas zurückgibt, aber er könnte möglicherweise die Fälschung zurückgeben. Das würde es ein bisschen glatter machen.

Gerade verifiziert:

f = sinon.fake();
val=sinon.replace(o, 'b', f)
assert.equal(f,val);

Das heißt, Sie können dies schreiben:

const foo = {bar: () => {}};
const fake = sinon.replace(foo, 'bar', sinon.fake());
foo.bar();
console.log(fake.calledOnce); // true

ja, macht Sinn. Außerdem gibt replace () seinen Rückgabewert nicht auf der Sandbox-Seite an

Machen Sie einfach klar, welche Versionen sich ändern sollten? Alle Versionen, die gefälscht haben, richtig? Oder nur die nächste Version?

Ein weiteres Feedback zur Dokumentation im Allgemeinen:

Ich kann verstehen, dass grüne Links sind, aber einige nicht grüne sind auch Links, wie sinon.replace* , sinon.spy und sinon.stub . Es wäre besser, sie irgendwie anders zu machen

Der erste PR befindet sich unter https://github.com/sinonjs/sinon/pull/2360 .

Ich warte auf Ihr Feedback.