Sinon: EcmaScriptモジュールのスタブを許可するようにノードを構成する方法を文書化する

私はまさにこれを書くことを考えていました:)

「問題」は、 esmを使用できるさまざまな方法が多数あることですが、少なくとも最も一般的なケースをカバーする必要があります。これは、 requireフラグを使用してnodeプロセス。 ここで設定ファイルの使用方法を具体化し始めましたが、環境変数としてjson文字列を指定することも可能であるようです（コードを使用する場合はオプションハッシュに加えて）。

こんにちは@ fatso83！

cjs.mutableNamespaceオプションはデフォルトで有効になっているため、構成は必要ありません。 スタブは.jsが、 .mjs .jsでは機能しません_（ .mjsファイルはロックダウンされているため、 esmオプションはありません）_。

@jdalton jsとmjs違いをお知らせいただきありがとうございます。 それが、この男がそれを機能させることができなかった理由を説明しています。

cc @ jim-king-2000

最小限のコストで単体テストを書きたいです。 解決策が非常に難しい場合は、モックを使用した単体テストを中止したいと思います。 結局のところ、模擬テストは堅牢なオンラインシステムを構築するための必須の方法ではありません。 しかし、最後の手段として、sinonが「proxyrequire」（またはこのようなもの）をラップする可能性はありますか？

@ jim-king-2000それは範囲外です。 エクスポートが不変であると想定されるモジュールシステムを使用することを明示的に選択しました。 残念ながら、それはあなたがあなた自身の側で負担しなければならない費用です。 モジュールローダーをラップして、あらゆる種類のシナリオ（ノード、ブラウザー、トランスパイラーの有無など）で機能させるには、コストがかかりすぎ、このプロジェクトで述べられている目標とは実際には何の関係もありません。

シノンとモジュールシステムの関連性がよくわかりません（ごめんなさい）。 私が必要としているのは、babelのないjs / nodeモックユニットテストフレームワーク（またはJavaの対応物であるmockitoのようなライブラリ）です。 それで、それは存在しますか？

要するに、あなたの特定のニッチのために：現在ではありません：sob：
一般的に：はい、フレームワークとランタイムのほぼすべての組み合わせでこれを実現する方法があります。

Javaの用語では、Java staticメソッドを使用してシステム全体を実装し、Mockitoを使用してクラスをモックアウトしようとするようなものです。 それはできません。

そうは言っても、物事を機能させるために必要なのは、 *.mjsファイルの名前を*.jsです。 これは実用的な中道のように思えます。既知の欠点がなくてもテスト容易性が得られるからです。

Javaの静的関数のモックには、powermockを使用します。 しかし、私はその比較を完全には理解していないかもしれません。 ちなみに、私はJavaが好きではなく、進化が遅すぎます。 今でもasync / awaitをサポートしていません。

私はどこでも* .mjsを使用していますが、すべてのソースコードはmjsファイルです。 さらに、それは私が再びbabelに頼らなければならないことを意味します（余分な開発/実行時の作業と厄介な呼び出しスタックを導入します）。 テストファイルを* .jsに戻すことしかできなくても問題ありません。

他の低コストの方法が見つかるまで、モックを使用してutを放棄します（他のテストはそのままです）。

@ fatso83ずっと助けてくれてありがとう。

誰かが口論を試みましたか？ 🤔

参考までに、モックライブラリである「testdouble.js」にNode.jsESMサポートを実装しました。 可能です。 私はこのブログ投稿で実装について書きました：

https://dev.to/giltayar/mock-all-you-want-supporting-es-modules-in-the-testdouble-js-mocking-library-3gh1

誰かがそれを引き受けたいと思ったら、ここで助けてくれると嬉しいです。

@giltayar ESMサポートの実装おめでとうございます！ 素晴らしい記事、ところで。 ESモジュールのスタブはESMランタイムに準拠することはできないと常に言ってきましたが、（上記のように）プロキシクワイア、再配線、または... Quibbleなどを使用してリンクレベルで処理する必要があるとも言いました。サポートを追加した場所:)

私の作業プロジェクトでは、 proxyquireを使用してESモジュールから依存関係をスタブアウトしました。

proxyquire('./mylib.mjs', {doSomething: () => 'done'})

これは、Quibble（TestDoubleで使用）でもまったく同じです。この記事にはこのような例がありますが、Quibbleは部分的なスタブをサポートしていないため、動作が少し異なります。

await quibble.esm('./mylib.mjs', {doSomething: () => 'done'}, 'yabadabadoing') // not sure what this third param does ...

したがって、前述の内容に沿って、SinonはESモジュールのモックのサポートを明示的に追加することはありません。これは、Quibble、Proxyquire、Rewire、 NormalModuleReplacementPlugin （webpack）、および100％環境である他のすべての方法に任せた方がよいためです。依存。

@ fatso83なぜこれが「明示的にサポートを追加しない」と確信しているのかと疑問に思うかもしれませんが、 ES6モジュールコードをモックするための解決策を必死に探している間、私はここ数日、ここで何度もそれを読みました。

Jestで文書化された解決策はなく、ここには何もありません。 @giltayarの記事を見つけるまで、私はほとんどあきらめました。 そのような安堵。 testdouble.jsを使用できることに気付くまで、quibbleで何かが機能するようになりました。

JavaScriptでは、すべてのパッケージに独自のドキュメントスタイルがあり、ほとんどの場合、実際のAPIドキュメントがないことはすでに十分に困難ですが、テストライブラリの動作、モックライブラリの動作、およびモックライブラリのモジュールローダーの動作を理解する必要があります。 。

他の人が「エンドユーザー」プログラマーのためにそれらのパッケージを一緒に配線することに集中できる一方で、あなたがそのままSinonに焦点を合わせると言うなら、私は完全に同意します。 私のようなプログラマーには本当に苦痛があることを示したいだけです。プロセスが簡素化されれば、特に多くの人が今後ESモジュールに移行する場合は、多くの人が喜ぶと確信しています。

私はそれほど深い技術的理解を持っていません、私は私の経験のいくつかのフィードバックが役立つかもしれないと思っただけです

@ fatso83なぜこれが「明示的にサポートを追加しない」と確信しているのかと疑問に思うかもしれませんが、

繰り返しになりますが、輸入品のモックを扱うことはSinonの範囲外であり、専門の図書館がより適切に取り組むというのはSinonのメンテナの意見です。

一般に、すべてのランタイムですべてを実行しようとするライブラリを作成することは意味がありません。 それほど大きくなく、資金が十分にあるオープンソースプロジェクトがこれを行おうとはしていません。

Jestで文書化された解決策はなく、ここには何もありません。 @giltayarの記事を見つけるまで、私はほとんどあきらめました。 そのような安堵。 testdouble.jsを使用できることに気付くまで、quibbleで何かが機能するようになりました。

ライブラリが異なれば、選択も異なります。

testdouble.jsのメンテナは独自の選択をします。 彼らは、quibbleを公開し、それをライブラリに統合することにしました。 彼らにとって良いことです。 あなたが彼らの解決策が好きなら、ぜひそれを使ってください。 @searlsと

JavaScriptでは、すべてのパッケージに独自のドキュメントスタイルがあり、ほとんどの場合、実際のAPIドキュメントがないことはすでに十分に困難ですが、テストライブラリの動作、モックライブラリの動作、およびモックライブラリのモジュールローダーの動作を理解する必要があります。 。

他の人が「エンドユーザー」プログラマーのためにそれらのパッケージを一緒に配線することに集中できる一方で、あなたがそのままSinonに焦点を合わせると言うなら、私は完全に同意します。 私のようなプログラマーには本当に苦痛があることを示したいだけです。プロセスが簡素化されれば、特に多くの人が今後ESモジュールに移行する場合は、多くの人が喜ぶと確信しています。

JavaScriptエコシステムのすべての問題を解決するためにここにいるわけではありません。

10年以上の間、さまざまなメンテナがSinonファミリーのライブラリを無料で提供してきました。 事実上、これらのライブラリの保守に費やされたすべての作業は、保守担当者の自由な時間に、無給の作業として行われています。 私たちはJavaScriptを専門的に使用しており、あなたの不満を共有しています。 しかし、無料で提供する時間はあまりありません。

私はそれほど深い技術的理解を持っていません、私は私の経験のいくつかのフィードバックが役立つかもしれないと思っただけです

依存関係をあざける欲求不満についてのブログ投稿を書いて、自分に合った解決策にたどり着くまで、そしてJavaScriptをロードする特定の方法でtestdouble.jsをどのように使用して大成功を収めたかについてブログに投稿すると便利です。

堅実なブログ投稿であることが判明した場合は、 sinonjs.org宣伝させていただきます。

@mroderick最初に、あなたとSinonのメンテナが私の最高の敬意を持っていることを明確にする必要があると思います！

JavaScriptエコシステムのすべての問題を解決するためにここにいるわけではありません。

確かにそうではありませんが、それは他の言語よりも助けの必要性が大きいかもしれないことを示すためだけのものでした（私の推測です）。

輸入品のモックを扱うことはSinonの範囲外であり、専門の図書館によってより適切に取り組まれています。

十分に公平なことですが、私が言ったように、私はそれを理解することができ、おそらくあなたはそれらの機能を実装することによって含まれる努力をより深く理解しているでしょう。 また、ローダーAPIはまだ実験段階です。

私は現在、動作するバージョンができ次第オープンソースとしてリリースする予定の小さなCLIツールに取り組んでいます。 それが行われたら、私はそれについてのブログ投稿を書くことを検討します。 私はSinonについてあまりにも多くの良いことを読んだので、以前はproxyquire Sinonを試します。

私はSinonについてあまりにも多くの良いことを読んだので、以前はproxyquire Sinonを試します。

その方法に関するガイドがあります： https ：

ガイドを改善できる場合は、プルリクエストを送信してください👍