[project-sequencer-statemachine] StoreをDIするように変更

[sigprogramming]

内容

StoreをDIするようにします。

関連 Issue

• ソング：シーケンサーのプレビュー処理をステートパターンで実装して置き換える #2403

その他

[voicevox-preview-pages]

🚀 プレビュー用ページを作成しました 🚀

• 📝 エディタ
• 📖 Storybook

更新時点でのコミットハッシュ：852d37e

[Hiroshiba]

すみません、ちょっと一旦方針だけ確認したく…！

スタートマシンできれいに単体テストできる構成だったのが、しづらくなりそうですね…！
そろそろテストを実装できればとも考えているのですが、どういう方針が良さそうでしょうか👀
（ソングエディタ全体でe2eテストを書く or スタートマシンで単体テストを書く or テストを諦める、など）　

ちなみにstoreをDIする形でも単体テストは可能です🙏
（storeをマックすれば良い）
ただシグネチャが変わる度にモック変えないとなので、単体テスト時はそれなりに不便かもです。

[sigprogramming]

@Hiroshiba
各ステートのロジックはコンポーネントのロジックでもあります。
（ステートを切り替えるとコンポーネントの振る舞いも切り替わる）
なので、単体テストよりコンポーネントテスト・E2Eテストの方がもしかしたら合っているかもしれません。
（テスト周り、あまり詳しくないので自信ないですが…）
https://ja.vuejs.org/guide/scaling-up/testing#unit-testing

単体テストを行うのであれば、storeのモックと、ブラウザのAPI（requestAnimationFrame、MouseEventなど）のモックが必要になると思います。
（storeのモックの作成は以前の形でも行う必要があると思います）

[Hiroshiba]

テストはちょっと僕もわかってないのですが、検証したい項目があり、効果が大きいとこでテストするのが良い気がしています！
ステートマシン単体でテストを書いておけば、ステートマシン自体のリファクタリングやバグ発見が容易にはなると思います。
ステートマシンがどれくらい壊れやすいか・どれくらい変更されやすいか次第かもです。

ステートマシンの単体テストの正常系は例えば、クリックしたらのノートが置かれる（実際にVuex状態変数が変わるのではなく、モック関数を仕込んでおく）、ノートを範囲選択したらステートが移動し想定した状態変数になる、何もないところを範囲選択しても状態が遷移しない、でも選択中に無を範囲選択するとIdleに戻る、とか･･･！
（どの状態に遷移しているかはe2eテストでは得られない）

ちなみにMouseEventのmockは相当簡単（オブジェクト作るだけ）なはずで、requestAnimationFrameは単体テスト時はいらないかも（というより要らないように作る）です！
e2eにするならどんな形でもstoreのモックは不要そう。store＋ステートマシンの複合テストをする際はmockがあっても良いかも。（とても大変そうだけど）

なんだかんだ言ってるけれども、結局ステートマシンがどれぐらい壊れやすいのものなのか先見の明がないので、テスト書くべきかどうかわからないんですよねー！！
テスト書くなら絶対に1枚挟んでおいた方が良い（PR前のDIしている形）のは知ってるのですが。。という感じでコメントしました！

うーーーーーーん。
おすすめは今の冗長構成にしといて、やっぱりめんどくさいなとなった＆テストを書かなくて良いなとわかったら外すとかでも良いかもです！
まあでもそんなに戻すのも難しくなさそうなので、今もうすでにめんどくさいとかであればstoreと密結合させちゃってもまあという感じです！！（きっと２年後に答えがわかる･･･！）