エディタのテスト周りを整備していく

[Hiroshiba]

VOICEVOXの開発から早半年が経過しました。 そろそろVOICEVOXのバージョン１に向けての準備を始めていく季節かもしれません。

目的

ソフトウェアの安定性の向上・開発スピードの向上

背景

VOICEVOXバージョン１に向けての課題の１つが、ソフトウェアの安定性です。 VOICEVOXはなかなかの数のバグがあったり、毎回何かしらのhotfixが入ったりしています。 バグはさておき、hotfixの方は結構単純なものも多く、たとえば「保存したプロジェクトファイルが読み込めない」などがあります。 このような単純なミスは、おそらくテストを整備することで回避できると思っています。 なのでこのプロジェクトでテストを整備していければと思っています。

ゴール

テストを整備する、というのは終わらないタスクになってしまうので、このissueではテスト実装方針が決まり、ある程度テストが書かれた時点で一旦完了にしたいと考えてます。

課題

テストを整備するにあたって最大の壁なのが、VOICEVOXエディタの規模の大きさです。 おそらく全体で１万行を超えており、テストもまったくない状況なので、どこからどう手を付ければ良いのかがわからない、というのが現状です。 このissueでは、まずどうやってテストを整備していけば良いのか議論するところから始まると思っています。

その他

webサービスやソフトウェアのテストを書いたことのある有識者の方からご意見もらえるととても心強いです･･･！

[Hiroshiba]

最初に聞きたいというか考えたいのですが、何のテストを実装すべきでしょうか。。

Vuex関数の１つ１つのユニットテストを書いていくのがパッと思いつくのですが、たぶんとんでもない量になってしまう気がしています。

テストの整備方法を色々調べてみると、工数が限られている場合は、そのサービスが実現したいユースケースを満たすようなテストを書いていくのが良い、みたいな記事を見かけました。 よくわかっていないのですが、例えば「起動したら、エラーが出ずに最初の画面に到達できる」「テキストを入力して再生ボタンを押せば音声が再生できる」みたいな、E2Eテストを実装していけば良いという感じでしょうか。。

本当に何も知らないので、なんでも教えて頂けるととても嬉しいです。

[tarepan]

概要

全テストを「unit（View, Model, Engine, Core）/ 機能（Editor, Engine API, Core API）/ E2E（各ストーリー）」に割り、よく壊れるところをまず書くのが常道.
現状はunit/機能/E2Eのどこがよく壊れるかわからない状態.
過去hotfixの解析が第一歩.

背景

テストベストプラクティス

全テストをピラミッドと見立て、

• unitテスト
  • エディタView（例: 保存ボタンがModelへ保存指示を通知するか）
  • エディタModel（例: Modelがエディタ状態を受け取るか、保存値が入力と一致するか）
  • エンジン関数（例: split_moraの入出力が意図通りか)
  • コア関数（例: initが初期値を設定するか)
• 機能テスト
  • エディタ機能 (例: 再生ボタンがView→Model→MockAPI→Model→Viewを通って再生を行えるか）
  • エンジンAPI（例: synthesis APIが全内部関数を呼んで意図した出力をするか）
  • コアAPI
• E2Eテスト（顧客価値・ユーザーストーリーを起点とするテスト）
  • 「先月ちょっと作った動画、続き作ろうかな」: proj読み込み （例: ファイル値 == エディタ状態、バージョン整合）
  • 「はじめて合成ためしてみる」: 音声synth（editor→engine→core→engine→editor, 例: エンジン起動中動作、合成速）

のように割るのが常道かと思います。

テスト方針

実際によく壊れる場所をテストする、が第一歩でよくある方針です。

現状

> 何のテストを実装すべきでしょうか は「ピラミッドのどこをテストするか曖昧」な状態だと思われます。

対策

まずhotfix履歴からどのレベルでよくコケるか調査するのがオススメです.
つまり「エディタModelのunitテストしとけば防げた」なのか「unit間連携にバグがあってAPIが壊れた」なのか「APIの組み合わせで、動きはするけどUXが意図したものじゃなかった」なのかを明らかにします.
これにより、エディタView unitテストが必要なのか、全通のE2Eテストが必要なのか明確になります.

[Hiroshiba]

詳細にありがとうございます！！ たしかに現状分析して穴が空いたことのある付近を塞ぐのが最優先ですね！！ その際の割り方がunit/機能/E2E･･･なるほどです！

過去のhotfixをリストアップしてみます。 ↑と相関していそうですが、そのバグの領域（DOM・Vuex・コンポーネント・Electronなど）もついでにメモします。

内容	unit/機能/E2E	領域	補足
読点でエラーが出る	unit	エンジン側
ファイル読み込み時のバグ	unit	Vuex
過去のプロジェクトファイルが読み込めない	unit	Vuex
日本語が含まれるパスで起動しない	unit	エンジン側
過去のプロジェクトファイルの調整結果が消える	unit	Vuex
プロジェクトファイルが読み込めない	uint	Vuex
複数行ペーストでエラーが出る	unit	Vuex
新規インストール時に音声が保存できない	unit	Electron	設定の初期値がおかしかった
古いバージョンのプロジェクトファイルが読み込めない	unit	Vuex
Linuxでエンジンが起動しない	機能	エンジン連携
Linux版がビルドできない	E2E	エンジン側
インストーラーがタイムアウトする	E2E	インストーラ
特定環境でエンジンが起動しない	機能	エンジン連携
デフォルトスタイル選択で完了が押せない	機能	コンポーネント/Vuex
プロジェクトファイルが読み込めない	uint	Vuex
途中に疑問形があるとおかしくなる	unit	エンジン側

ほぼほぼプロジェクトファイル周りのバグで、あとはunit/機能/E2Eがまんべんなくという感じでした。 プロジェクトファイルのバグをunitとしていますが、過去のプロジェクトファイルを読み込む場合はエンジンAPIを叩くこともあるので機能やE2Eの方が正しいかもしれません。

あと大体のバグが、正常系がうまく動作しないという内容でした。

とりあえずプロジェクトファイル周りの単体テストは必須で、あとは･･･どうしましょう。