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の種類/ディストリ/バージョン

• [x] Windows
• [x] macOS
• [x] Linux

関連 issues

• 730

[tarepan]

単体テスト実装状況

router 単位で集約。

• engine_info
  • [x] GET /version-200
  • [x] GET /core_versions-200
  • [x] GET /supported_devices-200
  • [x] GET /engine_manifest-200
• library
  • [ ] GET /downloadable_libraries
  • [ ] GET /installed_libraries
  • [ ] POST /install_library/{library_uuid}
  • [ ] POST /uninstall_library/{library_uuid}
• morphing
  • [x] POST /morphable_targets-200
  • [ ] POST /synthesis_morphing
• portal_page
  • [x] GET /-200
• preset
  • [x] GET /presets-200
  • [x] POST /add_preset-200
  • [x] POST /update_preset-200/422
  • [x] POST /delete_preset-204/422
• setting
  • [x] GET /setting-200
  • [x] POST /setting-204
• speaker
  • [x] GET /speakers-200
  • [x] GET /speaker_info-200
  • [x] GET /singers-200
  • [x] GET /singer_info-200
  • [x] POST /initialize_speaker-204
  • [x] GET /is_initialized_speaker-200
• tts_pipeline
  • [x] POST /audio_query-200
  • [x] POST /audio_query_from_preset-200/422
  • [x] POST /accent_phrases-200
  • [x] POST /mora_data-200
  • [x] POST /mora_length-200
  • [x] POST /mora_pitch-200
  • [x] POST /synthesis-200
  • [ ] POST /cancellable_synthesis
  • [ ] POST /multi_synthesis
  • [x] POST /sing_frame_audio_query-200
  • [x] POST /sing_frame_volume-200
  • [x] POST /frame_synthesis-200
  • [ ] POST /connect_waves
  • [ ] POST /validate_kana
• user_dict
  • [x] GET /user_dict-200
  • [x] POST /user_dict_word-200/422
  • [x] PUT /user_dict_word/{word_uuid}-204/422
  • [x] DELETE /user_dict_word/{word_uuid}-204/422
  • [x] 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できることを確認するとか･･･）