Vuexのユニットテスト実装方針をふんわり決めたい

[Hiroshiba]

内容

#2899 で Vuex のユニットテストの追加PRをいただきました！
良い機会なのでテスト実装の方針について整理したいです。

現在、このリポジトリではドキュメント化を進めていけると良さそうに思ってます（例： #2908 でE2Eテストの書式ドキュメント化を検討中）。
Vuexについてもユニットテストがまだ少ないので、今後テストを増やしていく際の参考になるよう、暫定的な方針を決めておきたいです。
「とりあえず今はこんな感じで」という温度感でも良さそう。

検討したい項目

このあたりが観点になりそう？

• Vuex.store.stateの作り方

  • 状態のmockを作るか、毎回実体を作るか
  • mockを作る場合は疎結合にできるけど、型エラーやテストごとの煩雑性が上がる
    • @akikukeo さんPRの実装がわかりやすい
  • 実体を作ると実装が簡単だけど、重くなる
    • こういう感じで毎回初期値にリセットする↓

      const initialState = cloneWithUnwrapProxy(store.state);
      beforeEach(() => {
        store.replaceState(initialState);
      
        resetMockMode();
      });

  • 個人的には簡単さを取っておいて、テストが重いなどの問題が起き始めたらどうするか考えると良いかなと

• テスト対象の選定基準

  • 「挙動が自明じゃないもの」を対象にするとか？
  • 例：setするだけの関数は自明すぎるのでテストしない
  • 変わった振る舞いをするものとか、計算が複雑なものとか
  • 個人的にはユースケースがあるなら複合テストにしてもOK派

• e2eテストとの棲み分け

  • 正直わからないので未定で良さそう感

ゴール

こんな感じで行こうという方針が決まって、ドキュメント化するかしないかが決まったら完了。

その他

• 元のコメント: feat: 音声の合計長さが分かる表示の追加 #2899 (comment)
• 関連PR: feat: 音声の合計長さが分かる表示の追加 #2899
• 関連Issue: E2Eテストのコーディングスタイルのドキュメントを考えて配置したい #2908（E2Eテストの書式ドキュメント化）

[sevenc-nanashi]

まだ自分でも決め切れてませんが、何らかの方法で「指定されていないstateにアクセスしたら失敗する」みたいなのがあると便利そうだなぁと思っています

[Hiroshiba]

なるほどです。どういうときに便利そうですかね？ 👀
例えば複雑なactionとかだと、中身がどのstateに依存しているかテストするのはむしろ詳細すぎてテストすべきじゃない気もするかも、みたいに思い。