add: API 単体テスト

[tarepan]

内容

要望概要: 全API実装へユニットテストを追加したい

VV engine は VV API (for マルチエンジン) の標準実装であり、かつ、中品質音声合成を実際に可能とするシンセサイザである。
そのため VV engine は以下の2つを保証する必要がある：

A. (API準拠) VV engine は VV API compatible である
B. (設計出力) VV engine は意図した値を出力する

この2つは API 実装たる app のユニットテスト (単体テスト) として保証可能である。
AとBは VV engine と外界の界面に対する保証であるため、最重要であり、全 API で確実に保証されるべきである。

このような背景から、VV engine 全 API 実装に対するユニットテスト追加を提案します。

Pros 良くなる点

• API 準拠の保証
• エンジン出力が意図通りであることの保証

Cons 悪くなる点

• テストメンテコスト増加
  • Pros と比較すれば微々たるものと考える

実現方法

1. API リストアップ
2. ユニットテスト実装状況リスト化
3. 各ユニットテスト実装

VOICEVOXのバージョン

0.16.0

OSの種類/ディストリ/バージョン

• Windows
• macOS
• Linux

関連 issues

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

[tarepan]

単体テスト実装状況

router 単位で集約。
TODO: preset を見本に 204 の snapshot

• engine_info
  • GET /version-200
  • GET /core_versions-200
  • GET /supported_devices-200
  • GET /engine_manifest-200
• library
  • GET /downloadable_libraries
  • GET /installed_libraries
  • POST /install_library/{library_uuid}
  • POST /uninstall_library/{library_uuid}
• morphing
  • POST /morphable_targets-200
  • POST /synthesis_morphing
• portal_page
  • GET /-200
• preset
  • GET /presets-200
  • POST /add_preset-200
  • POST /update_preset-200/422
  • POST /delete_preset-204/422
• setting
  • GET /setting-200
  • POST /setting (整理: POST /setting API にスナップショットを追加 #1375)
• speaker
  • GET /speakers-200
  • GET /speaker_info-200
  • GET /singers-200
  • GET /singer_info-200
  • POST /initialize_speaker-204
  • GET /is_initialized_speaker-200
• tts_pipeline
  • POST /audio_query-200
  • POST /audio_query_from_preset-200/422
  • POST /accent_phrases-200
  • POST /mora_data-200
  • POST /mora_length-200
  • POST /mora_pitch-200
  • POST /synthesis-200
  • POST /cancellable_synthesis
  • POST /multi_synthesis
  • POST /sing_frame_audio_query-200
  • POST /sing_frame_volume-200
  • POST /frame_synthesis-200
  • POST /connect_waves
  • POST /validate_kana
• user_dict
  • GET /user_dict-200
  • POST /user_dict_word-422 (整理: UUID を置換してスナップショットテストを有効化 #1349)
  • PUT /user_dict_word/{word_uuid}-204/422
  • DELETE /user_dict_word/{word_uuid}-204/422
  • POST /import_user_dict-204

[Hiroshiba]

issue 作成ありがとうございます！

AとBをどう分けるかが少し論点になりそうだと思いました。
B用のテストは出力値のスナップショットテストなどなどで、 A用のテストはstatus okが返ることを保証するだけ、みたいな･･･？

[tarepan]

AとBをどう分けるか

👍
同意です。

B用のテストは出力値のスナップショットテスト

👍
同意です。値ハードコード or スナップショットで意図した出力値を保証できると思います。

A用のテストはstatus okが返ることを保証

ここなんとも微妙ですね。
より安全側に倒すのであれば「response 200 + response 型バリデーション」という手もあります。
ただ「run.py が FastAPI ベースなので型安全性は確保されている」というのも事実です。
私としては「200 チェックだけすればいい…かなぁ…？」くらいの温度感です。

[Hiroshiba]

より安全側に倒すのであれば「response 200 + response 型バリデーション」という手もあります。

なるほどです！
個人的には値のチェックはそこまで必要ないと思ってたのですが、型のチェックくらいならやっても良いかもと思いました！

あ、いや、レスポンス内のkeyとかが変わってないことをテストしないとかもなので、キーチェックはあっても良い･･･かも･･･？
（あるいは同じ型をテスト側に実装して、parseできることを確認するとか･･･）