run.py・e2eテストを追加していく

[Hiroshiba]

内容

• run.pyのテストと全体のテストを書く #230

の続きissueの予定です。

どういうテストがあると嬉しそうかを列挙してみたいと思います！
大半のテストが完了してあとは個別にissueを分解できるようになればこの課題は解決です。

実現方法

#730 (comment) へ移動

音声ファイルのチェックはsoundfile.readで読んで配列の長さが0より大きければ多分OK？

その他

他にもAPIドキュメントにあるAPIを一通り通れると安心できそう！
https://voicevox.github.io/voicevox_engine/api/

[tarepan]

E2Eテスト進捗リスト

• 初級
  • 空白のテキストで/audio_queryすると固定値のAudioQueryが帰ってくる
  • /speakersで話者一覧が得られる
  • /singersで歌手一覧が得られる
  • /engine_manifestで固定値のエンジンマニフェスト情報が得られる
  • /settingで固定値の設定情報が得られる
  • /presetsでプリセットリストが取得できる
  • /user_dict_wordで単語を追加できる
  • /versionでバージョンが取得できる
• 中級
  • /speakersで得られた話者それぞれで/speaker_infoから追加の情報を得られる
  • /singersで得られた話者それぞれで/singer_infoから追加の情報を得られる
  • 「テスト」などのテキストで/audio_queryするとaccent_phrasesの中身が「テスト」なAudioQueryが返る
  • /audio_query→/synthesisで合成でき、音声ファイルが帰ってくる (PR: 整理: e2e TTS テスト #1064)
• 上級
  • 読み方を AquesTalk 記法で取得・修正する
  • ユーザー辞書登録をしたら/audio_queryの結果テキストの内容が変わり、ユーザー辞書リストにも追加されている
  • プリセット登録ができる
  • モーフィングができる
  • /settingで設定情報を変更できる
  • mutableAPI無効化設定が機能している

[tarepan]

@Hiroshiba
e2eテストの内容についての質問です。

VOICEVOX engineとして、e2eテストは「API単体テスト」と「API跨ぎユースケーステスト」のどちらをどれくらい実装する方向性でしょうか？
「API単体テスト」は上記の初級に相当するもので、建てた app の各APIを叩くテストです。徹底する場合、全APIにe2eテストを実装することになります。
「API跨ぎユースケーステスト」は上記の中級~上級に相当するもので、VOICEVOXとして想定するエンジン利用法を、複数APIを跨いでテストするものです。理論上は無限の選択肢があります。
この2種類の異なるテストをそれぞれどれくらい実装するかで、この issue の完了条件が変わりそうです。
方向性を教えていただければ幸いです。

[Hiroshiba]

「この issue の完了条件」とずれるかもですが、理想論はこうかなと！

• API単体テスト
  • 全ての正常系（よほど自明じゃない限り）
  • そこそこ起こりそうな異状系
• API跨ぎユースケーステスト
  • READMEで案内されてる流れを一通り

目的は開発の効率を上げることと、ユーザーがサードパーティアプリを作る時の問題をなるべく減らすことかなと。
（後者はUI/UX デザイン方針に従っています）

↑の理想論はかなり大きいのでタスクを分解しても良いかもと思いました。
というよりこのissueは現時点で達成している（少しテストが実装された）かもですね！

「API単体テスト」と「API跨ぎユースケーステスト」はディレクトリの名称を分けても良いかもと思いました。
例えば前者は unit/api ディレクトリ、後者は e2e ディレクトリとか！

[tarepan]

理想論はこう

👍
実装すべきテストが良く理解できました、ありがとうございます！

目的は

👍
案内ありがとうございます。テストは目的ありきなので、言語化されていることが素晴らしいです。

↑の理想論はかなり大きいのでタスクを分解

👍
同意です。
各テストが実装され始めたことで「理想論が思ったより広範囲だな」と気づけたことが本 issue の大きな副産物だと感じます。

「API単体テスト」と「API跨ぎユースケーステスト」はディレクトリの名称を分けても良い

👍
同意です。
かなり性質が違うテストなので、妥当な方針だと思います。

このissueは現時点で達成している

👍
この議論で浮かび上がった各課題を個別 issue で更に議論する形が良いと思います。
個別 issue への切り出しが終わった段階で、本 issue は close 可能そうです。

• add: API 単体テスト #1065
• 整理: API 単体テストディレクトリの追加 #1066
• add: API 複合テスト #1107

[tarepan]

いくつかのテストが実装され、個別のテストに関する後続 issues が整備されたため、本 issue は解決しました🎉