JavaScriptユニットテスト-モックまたはフィクスチャ？

Question

いくつかのオプションに興味があります...

私はJSのユニットテストをチームに導入します。これは主に、多くのdomインタラクションと更新を伴うテストモジュールです。

従来、jqueryなどのライブラリをテストするときは常にモックとスパイを使用していましたが、これはユニットテストの新しいチームであるため、フィクスチャを使用すると迅速に稼働できるようになると思いました。

フィクスチャの使用に関して私が抱えているいくつかの懸念は次のとおりです。

テストは、統合テストのようなものになる可能性があります。
ユニットテストが促進する、より適切に記述され、構造化され、抽象化されたコードの利点を失う。
備品はテストの速度を遅くします
器具のメンテナンスは隠れたオーバーヘッドになる可能性があります。

しかし、他の人の意見を聞いて本当に興味があります。

前もって感謝します

Arseni Mourzenko · Accepted Answer

実際、そのようなフィクスチャは単体テストを実行するための良い方法ではありません。単体テストの目的は、残りのコードや環境から分離して、コードの非常に特定の（そして多くの場合は非常に小さい）部分をテストすることです。これらのテストをWebページの特定の状態に依存させることにより、テストの「ユニット」の側面が失われます。つまり、代わりにシステムテストと統合テストが必要になります。

また、テストの速度の側面についても正しいです。 DOMはひどく遅いことが知られているため、テストがDOMに大きく依存している場合、数千のテストを1秒間に実行することを期待しないでください。

フィクスチャのメンテナンスが困難な作業である可能性があることも同様に正しいことです。基本的に、WebアプリケーションのHTML構造が変更された場合、それをすべてのフィクスチャに反映する必要があります。フィクスチャが手動で記述されている場合、それを行うのに多くの時間を無駄にします。フィクスチャが生成されると、ジェネレータ自体のチューニングに多くの時間を費やすことになります。

少なくとも何かをテストするか、何もテストしないかを選択するときに、アプローチの利点が顕著になります。プロジェクトが時間のプレッシャーにさらされている場合、フィクスチャはチームに自動テストを導入するのに適した選択肢です。

プロジェクトが十分に小さい場合、そのようなテストが必要な唯一のものである可能性があります。ユニットテストを追加しても、長期的にはあまり効果がなく、短期的にはプロジェクトに影響を与えます。
プロジェクトは大きいがユニットテストの完全なスイートを開発する時間がない場合は、フィクスチャを使用したシステムテストから始めます。十分なブランチカバレッジを取得したら、新しいコード、カバレッジが最小のコード、バグが最も多いコードに焦点を当て、クラスごとにユニットテストを追加します。

重要な利点は、コードベースが単体テスト用に適切に設計されていない場合、追加するとリファクタリングが必要になり、リグレッションが発生する可能性があることです。フィクスチャを使用したシステムテストが既に十分にある場合、少なくとも一部のリグレッションを検出するためのシステムテストがあることを知っていれば、チームは後でユニットテストを追加するときにリファクタリングをより快適に行うことができます。