Zenn
Closed8

Nuxt(SPA)の自動テストを考えるメモ

Nuxt
Vue.js
Jest
#
ユニットテスト
（や）（や）

テストサイズについて

テストサイズについては以下の箇所に説明が記載されている。

テスト自動化の観点で考えた場合に、テストサイズの考え方によってどのようなテストコードを書くかの指標になる。

テストサイズの分類

  • Small - テストメソッドごとに100ms未満で実行。ネットワーク、DB、ファイルシステムにはアクセスしない前提
  • Medium - テストメソッドごとに1秒未満で実行。ネットワークアクセスはlocalhost onlyなど。
  • Large - 出来る限り高速に実行。ネットワーク、DB、ファイルシステムへのアクセス可能

CIとの連動について

テストサイズとCIタイミングは以下の分類だと良さそうに感じる。

  • Small - push時
  • Medium - PRマージ時、developマージ時 or ステージング環境環境リリース時
  • Large - ステージング環境環境リリース時、本番環境リリース時
（や）（や）

テストサイズ - Small

ユニットテスト

  • 対象ファイル: 設定ファイル以外の全てのファイル
  • テスト対象: publicメソッド
  • テスト内容: メソッドの処理が想定通りに動作するかテストする
  • モックの適応範囲: Jestのモック機能を使用
  • mount or shallowMount: shallowMount
  • メモ:
    • カバレッジを測定することでテストがどこまで網羅しているか確認できる。
    • 異常系やprivateメソッドで到達しにくい箇所もあるのでカバレッジ100%は目指さないようにする。

スナップショットテスト

  • 対象ファイル: components/pagesの.vueファイル
  • テスト対象: templateのv-if, v-forに対応するdata/props/computed/methods
  • テスト内容:
    • templateのv-if, v-forが切り替わるテストケースを準備する。
    • JestのtoMatchSnapshotを使用してDOM構成を保存する。
    • 次回変更時にDOM構成にデグレがないかチェック出来るようになる。
  • モックの適応範囲: Jestのモック機能を使用
  • mount or shallowMount: shallowMount
  • メモ:
    • 規模が小さいプロジェクトの場合、ユニットテストのファイル内に含める。規模が増えてきた場合はユニットテストと分離して実行出来るようにした方が良い。
    • templateのv-if周りが複雑化している場合のデグレチェックとして役に立つ。スナップショットテストを記載後にtemplate側のリファクタリングを行うとよい。
（や）（や）

テストサイズ - Medium

コンポーネント結合テスト

  • 対象ファイル: pagesの.vueファイル
  • テスト対象: publicメソッド
  • テスト内容: コンポーネントを結合して、props/emitが正常にコンポーネント間で連携するか確認する
  • モックの適応範囲: ネットワークアクセスはJestのモック機能を使用
  • mount or shallowMount: mount
  • メモ:
    • propsまわりの変更がある場合にtoMatchSnapshotを使用してDOM構成をチェックするのもあり

ネットワークアクセステスト

  • 対象ファイル: ネットワークアクセスをしているファイル
  • テスト対象: ネットワークアクセスをしているメソッド
  • テスト内容: ajax処理が正常に動作するかテストする
  • モックの適応範囲:
    • ネットワークアクセス以外はJestのモック機能を使用
    • ajaxのアクセス先はJSON Serverやmsw、Docker環境でテスト用のAPIサーバーを立てるなど
  • mount or shallowMount: shallowMount
  • メモ:
    • コンポーネント結合テストに含めても結合テストとして扱ってもよい。
    • 観点を分けたり、テスト実行を分離したりしたい場合に分ける感じ。

ビジュアルリグレッションテスト

  • 対象ファイル: componentsの.vueファイル
  • テスト対象: -
  • テスト内容: コンポーネントのデザインにデグレがないかテストする
  • モックの適応範囲: StoryBook関連のモックライブラリを使用
  • mount or shallowMount: -
  • メモ:
    • 2022年2月現在、Storybook + Storycap + reg-suit を連携してビジュアルリグレッションテストを実施するのがメジャーかな
    • Storybook を使用していない場合、新規にStorybookのコードを書いたり、メンテナンスする必要があるので費用対効果を考える
    • CSSまわりのスタイル崩れのデグレが頻繁に起こっている場合は導入した方がよい
（や）（や）

テストサイズ - Large

e2eテスト

  • テスト内容:
    • Docker上で本番環境に近い構成にして実際にWEBサーバーに配置してテストする
    • ユースケース・シナリオベースで重要な箇所をテストする
    • jestからpuppeteerやselenium-webdriverなどを使用してWEBページを操作する
    • jest-image-snapshotなどで実際に表示されているWEBページの画像をスナップショットテストするのもよい
  • メモ:
    • 改修によって影響を受けやすい箇所なので、テスト数は極力少なめにしたい

パフォーマンステスト

  • テスト内容:
    • ページに最大数のデータをレンダリングして想定通りの描画時間になるかテストする
    • APIのテストはバックエンド側で実施するのでフロント側のパフォーマンステストには含めない
  • メモ:
    • e2eテストとちがいレンダリング速度を測定したいため、APIなどはモックでもよい
（や）（や）

テストケースの配分について

  • JavaScript Testing Trophyを参考にテストサイズがMediumのものを厚めに出来るとよいかも
  • Testing TrophyのStatic部分については以下の方法でチェックする
    • eslintやTypeScriptのコンパイラ設定を強くする
    • SonarCloudなどで複雑度や重複コードのチェックする
このスクラップは2022/02/12にクローズされました