ユニットテストのためにAngularにJestを導入する


ユニットテストのためにAngularにJestを導入する


なぜKarmaからJestに移行したのか


Karmaでプロジェクトで穴にあいました


最近新しく1つのプロジェクトを交換して、行った時にプロジェクトはすでに2ヶ月をして、前期の急いで機能するため、ユニットのテストに対して要求をしていないで、CI/CDの時も強制的にユニットのテストを走っていません.したがって,Angular CLIが自動的に生成したテストファイルがあるが,基本的にはテストが不合格である.プロジェクトが長くなって、人員の変動が多くて、新しく来たメンバーは前の業務の論理に対してはっきりしないで、少し注意しないと前の機能を破壊します;業務が複雑になると、少しでも機能を増やしたり修正したりして、気づきにくいバグを引き起こす可能性があります.敬業の開発として、ユニットテストに行かないとどうすればいいですか.したがって、既存のユニットテストを修復するタスクがあります.既存のテストファイルを修復する考え方は簡単です.TestingModuleを書いて、よく使われる依存mockを落として、必要なファイルに導入すればいいです.あまり使わない依頼は、それぞれのファイルでmockを落とすといいでしょう.しかし実際に操作すると、Karmaは早く穴を掘って待っていた.一部のテストファイルは単走で問題がなく、全体が走ったときに間違いを報告し、テスト結果と不安定である.karmaのエラーメッセージは特に読みにくく、どこが問題なのか分からないことが多い.さらにKarmaはAngularアプリケーションをコンパイルしてからブラウザでテストする必要があり、全体の時間も遅く、修復の過程は狂った縁にある.全体テストで走っているときにテストミスの位置を特定するのは難しいですが、どうすればいいのでしょうか.AngularではJest大法も非常に使いやすいことが実証されている.

KarmaとJestの対比


前述したように、修復テストの過程でkarmaは様々な問題に直面した.まとめると大体:
  • KarmaはまずAngularアプリケーション全体をコンパイルした後、ブラウザでテストを実行する必要があります.テストを実行する時間は比較的長いです.
  • Karmaのテスト結果は不安定で(非同期操作による可能性が高い)、単一ファイルと全体テスト時のテスト結果は一致しない.
  • エラーメッセージがぼやけていて、問題を特定できません.特に,大量のテストで修復が必要な場合,問題の根本原因を特定することが困難である.

  • 対照的に、Jestはこれらの面で良い表現をしています.
  • 全体のコンパイルを必要とせず、単一ファイルで
  • をテストできます.
  • 試験結果安定
  • 誤報がはっきりしていて、位置決め問題
  • が容易である.
    Jestには次のようなメリットがあります.
  • 開梱即用、基本的にはファミリーバケツであり、テストに必要なツールの大部分を含む:テスト構造、断言、spies、mocks
  • は、テストオーバーライド率レポート
  • を直接提供します.
  • スナップショットテスト
  • 非常に強力なモジュールレベルmock機能
  • watchモードは、修正されたファイルに関連するテストのみをテストし、非常に速い
  • いどう


    最初のステップは、依存パッケージが必要です.
    npm install --save-dev jest jest-preset-angular @types/jest

    次のようになります.
  • jest–Jestテストフレームワーク
  • jest-preset-angular–jest angularのいくつかの一般的な事前設定
  • @types/jest–Jestのtypings
  • 2つ目はpackageでJsonでJestを構成するには:
    "jest": {
      "preset": "jest-preset-angular",
      "setupFilesAfterEnv": ["/src/setupJest.ts"]
    }

    ここで、presetはプリセットを宣言し、setupFilesAfterEnvはJest setupファイルのアドレスを構成し、複数のファイルを含むことができ、ここではプロジェクトルートディレクトリの下のsrc/setupJest.tsを設定する.
    ステップ3では、srcディレクトリの下に、前のステップで設定したsetupファイルsetupJest.tsを作成します.
    import 'jest-preset-angular'; // jest   angular  
    import './jestGlobalMocks'; // jest   mock

    第4のステップでは、srcディレクトリの下にjestGlobalMocks.tsファイルを作成し、関連するグローバルmockを追加します.以下は例です.
    const mock = () => {
      let storage = {};
      return {
        getItem: key => key in storage ? storage[key] : null,
        setItem: (key, value) => storage[key] = value || '',
        removeItem: key => delete storage[key],
        clear: () => storage = {},
      };
    };
    
    Object.defineProperty(window, 'localStorage', {value: mock()});
    Object.defineProperty(window, 'sessionStorage', {value: mock()});
    Object.defineProperty(window, 'getComputedStyle', {
      value: () => ['-webkit-appearance']
    });

    この例では、jsdomがすべてのwindow上のオブジェクトと方法を実装していないため、自分でwindowにパッチを付ける必要がある場合があります.ここでmock localStorageはオプションであり、コードで使用されていない場合はオプションです.ただしmock getComputedStyleは、Angularがどのブラウザで実行されるかをチェックするため必須です.mock getComputedStyleがなければ、私たちのテストコードは実行できません.
    次はpackageでjsonのscriptでtestを構成するコマンド:
    "test": "jest",
    "test:watch": "jest --watch",

    このうちtestは1回のテストのみを実行し、test:watchはファイルの変化を検出し、現在修正されているファイルに関するテストを実行することができます.
    この場合、コマンドラインでテストコマンドを実行すれば、スムーズにテストを走り出して合格できるはずです.もし合格しなかったら、私たちがsrc/tsconfig.spec.jsonのfile構成にtest.jsの構成があるからかもしれません.これはKarmaのsetupファイルです.この行の構成を削除して対応するファイルを削除します.(src/tsconfig.app.jsonに現れたtest.jsも一緒に削除できます)、テストコマンドをもう一度実行します.
    npm run test

    これで、Jestテスト環境は順調に構築されました.コードに潔癖がある場合は、Karmaの関連コードを削除して、テストをすべてJestに変更することもできます.

    Karma関連コードの削除

  • 関連依存パッケージの削除(@types/jasmine@types/jasminewd 2 jasmine-core jasmine-spec-reporter e 2 eテストで使用されているため削除できません):
    npm uninstall karma karma-chrome-launcher karma-coverage-istanbul-reporter karma-jasmine karma-jasmine-html-reporter
  • 削除ファイルsrc/karma.config.js
  • angularを削除します.jsonにおけるtestの構成
  • src/tsconfig.spec.jsonのうちcompilerOptions.typeの構成はjasmineを除去しjestを加える.

  • これで、Karmaに関連するすべてのコードを削除しました.テストの断言をjestのスタイルに変えることもできます.最後に生成されたコード・ライブラリと関連ファイル構成の表示
    参照先:
  • Angular 6: “ng test” with Jest in 3 minutes
  • TESTING ANGULAR FASTER WITH JEST