make_docs.pyのSettingLoaderをMock化したい

[aoirint]

内容

#711 で提案した内容です。

APIドキュメントを生成するmake_docs.pyでは、実際に設定ファイルをファイルシステムから読み込む機能を持ったSettingLoaderをインスタンス化していますが、ドキュメントの生成には実際の機能は不要なため、ダミーの設定を返すMockに置き換えたいです。

Pros 良くなる点

• make_docs.pyの機能が単純になる
• generate_appを再利用しやすくなる

Cons 悪くなる点

• コード量が増える

実現方法

• SettingLoaderのインタフェースを定義する抽象クラスSettingLoaderBaseを作成する
• SettingLoaderがSettingLoaderBaseを継承するようにする
• SettingLoaderBaseを継承するMockSettingLoaderを作成する
• generate_appの引数setting_loaderの型をSettingLoaderBaseに変更する
• make_docs.pyのgenerate_app呼び出しでSettingLoaderの代わりにMockSettingLoaderをインスタンス化するようにする

VOICEVOXのバージョン

0.15 開発版

その他

関連Issue

• run.pyのgenerate_appなどの関数を分離していく #501

[Hiroshiba]

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

SynthesisEngineとSynthesisEngineBaseみたいに、ということですよね！　すごく良いと思います！！

[tarepan]

Mock化の必要性が低減した、と考えています。

Mock化の利点は次の2点かと思います：

A. 処理スキップによる高速化
B. 設定ファイルへの配慮不要化による容易化

#855 により、SettingLoader は設定ファイル無しで機能するようになりました。
よって SettingLoader は設定ファイルへの配慮無しに make_docs.py 等で利用可能、つまり B の利点が無くなりました。
Aの速度は実務上ほぼ無視できるため、Mock化の利点はほぼ無くなりました。
Interface導入は想像以上にメンテコストが掛かるため、利点無しで導入するにはデメリットが大きいです。

よって、状況の変化により、Mock化の必要性は無くなったと考えます（issue close可能）。

[Hiroshiba]

なるほどです！

他にも、まあ将来設定値を変えた場合のrun.py全体のテストとかをしたくなったら設定のmockが必要になるかもなのですが、その場合はどちらかというとSettingLoaderをmockにするよりSetting構造体をDI可能にする形を取る気がします。

他にはちゃんと設定が保存されるかなどのテストにもmockは便利そうですが、現状設定ファイルパスがDI可能になっているため、tmpファイルのパスを指定すればそのテストもあまり不自由なく可能そうです。

ということでmock化は必然ではなくなったと判断し、closeさせていただきます！