Sinon: 将来のマイルストーンのアイデア

@ sinonjs / coreにpingを実行します

良い提案、モーガン。 これを持ってきてくれてありがとう。 また、 stub APIは混乱していると思いますが、すべての提案が気に入っています。 ここにいくつかの考えがあります：

sinon.fake

ここで不変性が重要であることに同意します。 ただし、スタブで現在可能ないくつかの「正常な」ユースケースを許可することもできます。

たとえば、次のものを生成して返すための有効なユースケースである可能性があります。

sinon.fake({
  yields: [null, 42],
  returns: true
})

何が理にかなっていて、何が理にかなっていないかを確認できます。

また、構成としてcallsThrough: trueをサポートしている場合（これは、動作プロパティのいずれかとの組み合わせでは無効です）、「スパイ」APIの代わりに新しい偽物を使用することもできます。 これは、Sinon-speakで「スパイ」と「スタブ」が何を意味するかを学ぶよりも自明です😄

デフォルトのサンドボックスを使用する

私はこのアイデアが好きですが、テストの後にsinon.restore()を呼び出すと、他のテストの残りの部分が元に戻り、驚くべき結果が得られる可能性があります。 これにより可能になる素晴らしいことは、グローバルサンドボックスをbeforeEachにリセットして、テストの分離を改善することです。 👍

sandbox.replace

私はこれがとても好きです。 私はこれを「このことをそこに貼り付けさせてください」というユーティリティとして理解していますよね？

また、callsThrough：trueを構成としてサポートしている場合（これは、動作プロパティのいずれかとの組み合わせでは無効です）、「スパイ」APIの代わりに新しい偽物を使用することもできます。 これは、Sinon-speakで「スパイ」と「スタブ」が何を意味するかを学ぶよりも自明です😄

それは、 spyまたはstubがまったく必要ないことを意味しますか？

sandbox.replace

私はこれがとても好きです。 私はこれを「このことをそこに貼り付けさせてください」というユーティリティとして理解していますよね？

ええ、それはアイデアでした。 同じメソッド（ sinon.stub ）をオーバーロードして多くのことを行う代わりに、1つのことだけを行う明示的なメソッドを使用します

強調したように、 fake APIは、スパイとスタブで現在可能なすべてをサポートするわけではないでしょう。 しかし、ええ、 fake APIは、 stubとspyの機能を統合する機会だと思います。

私はこのアイデアが好きですが、テストの後にsinon.restore（）を呼び出すと、他のテストの残りの部分が元に戻り、驚くべき結果が得られる可能性があります。 これにより可能になる素晴らしいことは、beforeEachのグローバルサンドボックスをリセットして、テストの分離を改善することです。 👍

これは確かに重大な変更であり、軽く導入するべきではありません。

fakeを作成するときに、動作構成を渡さない場合は、 spyと同等になります。

// ~spy, records all calls, has no behaviour
const fake = sinon.fake();

// ~stub, records all calls, returns 'apple pie'
const fake = sinon.fake({
    returns: 'apple pie'
});

それでは何もしないスタブをどのように作成しますか？

それでは何もしないスタブをどのように作成しますか？

私はあなたの質問を完全に理解しているかどうかわかりません...しかしここに行きます

// a fake that has no behaviour
const fake = sinon.fake();

// put it in place of an existing method
sandbox.replace(myObject, 'someMethod', fake);

ああ、私はあなたが今何を意味しているのか理解していると思います： fakeは常にstubです。 ~spy, records all callsと言ったとき、私は「元の関数への呼び出し」を理解しました。 ただし、 fakeには、置き換えられる関数についての知識がありません。これがsandbox.replaceの機能です。

それを念頭に置いて、現在のspy機能を（コールスルーのように）新しい偽物に折りたたむ方法について、別の提案を示します。

const fake = sinon.fake(function () {
   // Any custom function
});

与えられた関数は偽物によって呼び出されます。 このAPIを使用すると、他の動作と混在させることができなくなります。 実際、configオブジェクトは、指定された動作を実装する関数を作成し、それを偽物に渡します。

sandbox.spy(object, method)の実装は、次のようになります。

const original = object[method];
const fake = sinon.fake(original);
sandbox.replace(object, method, fake);

基本的にワンライナー🤓

うん。 物事を単純化したら、楽しみのためにリミキシングを開始できます🎉と利益💰

ただし、 fakeを使用するだけで、 spyとstubを使用しないようにする場合は、これら2つをそのままにしておく必要があります。

ここで「次の」APIについて考えています。 どこかに置換ロジックを配置するには、 sandbox.spyが必要になります。 私が理解しているように、それは下位互換性があるはずです。 その後、 stubの実装は非推奨になる可能性があります。

置換ロジックをどこかに置くには、sandbox.spyが必要になります。 私が理解しているように、それは下位互換性があるはずです。 その後、スタブの実装は非推奨になる可能性があります。

フォローするかどうかわかりません。 詳細を教えていただけますか？

もちろん。 私はあなたの提案を理解しているので、あなたは過度に複雑なstub APIの代わりを望んでいます。 スタブが現在実装されている方法は、動作を実装する関数を使用してspyを作成することです。 私が提案しているのは、 fake APIで同じことを行い、内部でspyを作成することですが、連鎖をなくしたいので、動作を返すことはもうありません。 。 スパイを返すだけです。 これにより、 fakeの実装がstubの代わりになり、返された関数は現在のすべてのSinonAPIと互換性があります。 それは理にかなっていますか、それとも私は何かが足りませんか？

OK、私たちは同じような理解を持っていると思います👍

繰り返しになりますが、何かを見逃した場合に備えて、他の寄稿者も同じように理解できるようにします。

TL; DR

• すべての置換は新しいユーティリティによって行われます： sandbox.replace （これは現在stubあります）
• sinonにはデフォルトのサンドボックスがあり、 sinon.resetとsinon.restoreを使用できます（これらをマージするだけでよいですか？）
• sinon.fake —すべての呼び出しを記録する関数の不変でプログラム可能な置換
• sinon.spy
• sinon.stub

// effectively a spy that has no target
const fake = sinon.fake()

// spy on a function
const fake = sinon.fake(console.log);
const fake = sinon.fake(function() { return 'apple pie'; });

// a shorthand construction of fake with behaviour
const fake = sinon.fake({
    returns: 'apple pie'
});

// replacing an existing function with a fake
var fakeLog = sinon.fake();
sandbox.replace(console, 'log', fakeLog);

この状態では、提案はFunctionのみを扱います。 非関数プロパティとアクセサーについてどうするかを検討する必要があります。 少なくとも、 sandbox.replaceを制限して、正常な交換のみを許可できるかどうかを確認する必要があります。

これは、 sinon.stub()とsinon.spy()の両方が将来廃止され、 sinon.fake()が優先される、または単に内部でやり直されることを意味しますか？ もしそうなら、私たちは本質的にTestDoubleの考え方に向かっています。 IMHO、必ずしも悪いことではありませんが、多くの人がSinon api呼び出しをすべてsinon.fake()で置き換える必要があることに気付いた場合は、別のライブラリを使用することもできます（ただしつまり、SinonのAPIに関する既存の知識がすべて失われることになります）。

これは、sinon.stub（）とsinon.spy（）の両方が将来廃止され、sinon.fake（）が優先されることを意味しますか、それとも内部でやり直されるだけですか？ もしそうなら、私たちは本質的にTestDoubleの考え方に向かっています。

多少重なっていると思います。 この提案の私の主な動機は、不変の振る舞いをする偽の機能を持つことです。

IMHO、必ずしも悪いことではありませんが、多くの人が、sinon.fake（）のすべてのSinon api呼び出しを置き換える必要があることに気付いた場合は、別のライブラリを使用することもできます（ただし、 SinonのAPIに関する既存の知識をすべて失うことを意味します）。

人々が別の図書館が彼らのニーズをよりよく満たすと思うなら、私たちは彼らがそれを学ぶのを手伝ったことを嬉しく思います:)

しかし、スパイメソッドとスタブメソッドを維持するのでしょうか、それとも非推奨にするのでしょうか。機能が低下する可能性もあります。 それは私にはわかりませんでした。

しかし、スパイメソッドとスタブメソッドを維持するのでしょうか、それとも非推奨にするのでしょうか。機能が低下する可能性もあります。

fakeが安定しているように見えたら、 spyとstubを廃止し、1年のように人々がアップグレードできるようにします。

人々がコードを移動できるように、コードモッドと優れたドキュメントを提供するために最善を尽くすべきだと思います

私はこれの最初の部分（デフォルトのサンドボックス）のブランチに取り組んでいます。 sandboxとcollectionが1つになるように、コードをリファクタリングしました。 デフォルトのサンドボックスが機能するようになりました。

今後数日間でコミットを整理してから、このリポジトリに更新されたAPIのブランチを作成します。

これは素晴らしいアイデアであり、非常によく書かれています。

また、スタブとスパイに非推奨の通知を追加します。

また、関数を渡すことで、キーを使用してオブジェクトを渡すことを変更することも考えていました。

これにより、次の利点が追加されます。

• これにより、 typescriptまたは他の種類の静的チェッカーを使用したいユーザーの関数にtypeを追加できます。
• 存在しない動作に対して関数を呼び出そうとすると、ユーザーはエラーを受け取ります
• これらの機能を個別に文書化して、ドキュメントをさらに改善することができます
• それらの振る舞いに意味をなさない引数を渡すときに有用なエラーを提供し、それらがオプション/複数の引数を持つことを許可する可能性があります
• これにより、物事がより構成可能になり（この場合、このケースはあまり見られませんが）、作成された動作を再利用できるようになります。
• IMOこれは、動作するオブジェクトを持つよりも簡単です

したがって、APIは代わりに次のようになります。

// It would be cool to allow users to import these using destructuring to make code more concise
import { resolves, rejects, returns } from 'sinon/behaviors'; 

var fake = sinon.fake(resolves('apple pie'))

var fake = sinon.fake(rejects(new TypeError('no more pie')));
var fake = sinon.fake(rejects('no more pie'));

var fake = sinon.fake(returns('apple pie'));

var fake = sinon.fake(throws(new RangeError('no more pie'));
var fake = sinon.fake(throws('no more pie'));

これを実装することになると、提案しているような非常に単純なオブジェクトを返すだけの問題になる可能性があります。 次に、複数の動作がある場合は、それらをマージするだけです。

また、 onThirdCallとwithArgsのようなものを混合することになると、それらの場合に何が起こるかを文書化する必要があると思います。

これを遅くレビューしてすみません。 ここ数ヶ月はとても忙しかったです。

@lucasfcostaはPR＃1586をチェックしてください

この問題は、最近のアクティビティがないため、自動的に古いものとしてマークされています。 それ以上のアクティビティが発生しない場合は閉じられます。 貢献していただきありがとうございます。

5.0.0の前のバージョンは、package.jsonの新しい5.0.0-next。*プレリリースバージョンで問題を引き起こしています。これは、5.0.0がどのプレリリースバージョンよりも大きいためです。

5.0.0が出ているので、 nextのプレリリース番号をおそらく5.0.1-next.1に上げる必要があると思いますか？

私が使用していた別のパッケージが非推奨のメッセージを取得していて、そのpackage.jsonが"sinon": "^5.0.0-next.4"に依存しているため、これに気づきました

npm WARN deprecated [email protected]: this version has been deprecated

これがプレリリースの問題について新しい問題を開く価値があるかどうかはわかりませんでした。そのため、ここでのコメントが最も安全であるように思われました。

別の解決策は、次のメジャーバージョンをリリースすることです。 @ sinonjs / coreについてどう思いますか？

@ mroderickv5のすべての変更が何であるかはもうわかりません。 私の最後のテストからそれはうまくいきました、そして私は新しい偽物を使うのを楽しみにしています。 それは新しいメジャーなので、ちょっと、それを出荷してください😄

次のメジャーバージョンをリリースする前に、マージしたいPR＃1764がもう1つあります。

私は[email protected]を公​​開しましたが、それが当面の人々の生活を楽にしてくれることを願っています。

おかげで、package.jsonで依存関係をテストしました（常に再確認するのが良いです）。一致するものが見つからない（リリースがまだない）ため、 "sinon": "^5.0.1"はエラーを表示し、 "sinon": "^5.0.1-next.1"そのバージョンを取得すると正しく動作します。

これは決して大したことではありませんでした。特にv5がしばらく開発中であったことを知ったときは、知っておく価値があると思いました。リリースされるまでの期間はわかりませんでした。 近い将来にリリースするのは良い考えのように思えます。

fakeは＃1768で導入され、 [email protected]になりました