Open Hiroshiba opened 2 years ago
最初に聞きたいというか考えたいのですが、何のテストを実装すべきでしょうか。。
Vuex関数の1つ1つのユニットテストを書いていくのがパッと思いつくのですが、たぶんとんでもない量になってしまう気がしています。
テストの整備方法を色々調べてみると、工数が限られている場合は、そのサービスが実現したいユースケースを満たすようなテストを書いていくのが良い、みたいな記事を見かけました。 よくわかっていないのですが、例えば「起動したら、エラーが出ずに最初の画面に到達できる」「テキストを入力して再生ボタンを押せば音声が再生できる」みたいな、E2Eテストを実装していけば良いという感じでしょうか。。
本当に何も知らないので、なんでも教えて頂けるととても嬉しいです。
全テストを「unit(View, Model, Engine, Core)/ 機能(Editor, Engine API, Core API)/ E2E(各ストーリー)」に割り、よく壊れるところをまず書くのが常道.
現状はunit/機能/E2Eのどこがよく壊れるかわからない状態.
過去hotfixの解析が第一歩.
全テストをピラミッドと見立て、
split_mora
の入出力が意図通りか)synthesis
APIが全内部関数を呼んで意図した出力をするか)のように割るのが常道かと思います。
実際によく壊れる場所をテストする、が第一歩でよくある方針です。
> 何のテストを実装すべきでしょうか
は「ピラミッドのどこをテストするか曖昧」な状態だと思われます。
まずhotfix履歴からどのレベルでよくコケるか調査するのがオススメです.
つまり「エディタModelのunitテストしとけば防げた」なのか「unit間連携にバグがあってAPIが壊れた」なのか「APIの組み合わせで、動きはするけどUXが意図したものじゃなかった」なのかを明らかにします.
これにより、エディタView unitテストが必要なのか、全通のE2Eテストが必要なのか明確になります.
詳細にありがとうございます!! たしかに現状分析して穴が空いたことのある付近を塞ぐのが最優先ですね!! その際の割り方が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の方が正しいかもしれません。
あと大体のバグが、正常系がうまく動作しないという内容でした。
とりあえずプロジェクトファイル周りの単体テストは必須で、あとは・・・どうしましょう。
VOICEVOXの開発から早半年が経過しました。 そろそろVOICEVOXのバージョン1に向けての準備を始めていく季節かもしれません。
目的
ソフトウェアの安定性の向上・開発スピードの向上
背景
VOICEVOXバージョン1に向けての課題の1つが、ソフトウェアの安定性です。 VOICEVOXはなかなかの数のバグがあったり、毎回何かしらのhotfixが入ったりしています。 バグはさておき、hotfixの方は結構単純なものも多く、たとえば「保存したプロジェクトファイルが読み込めない」などがあります。 このような単純なミスは、おそらくテストを整備することで回避できると思っています。 なのでこのプロジェクトでテストを整備していければと思っています。
ゴール
テストを整備する、というのは終わらないタスクになってしまうので、このissueではテスト実装方針が決まり、ある程度テストが書かれた時点で一旦完了にしたいと考えてます。
課題
テストを整備するにあたって最大の壁なのが、VOICEVOXエディタの規模の大きさです。 おそらく全体で1万行を超えており、テストもまったくない状況なので、どこからどう手を付ければ良いのかがわからない、というのが現状です。 このissueでは、まずどうやってテストを整備していけば良いのか議論するところから始まると思っています。
その他
webサービスやソフトウェアのテストを書いたことのある有識者の方からご意見もらえるととても心強いです・・・!