Re: モッククラス、下から見るか？横から見るか？

f:id:kyon_mm:20190822153935j:plain

先日Twitterでリプライがきたのでみてみたら素晴らしいブログ( モッククラス、下から見るか？横から見るか？ )がありました。

プログラムにおける自動単体テストでモックをつかうべきかどうか悩んでいるというもの。

私なりにこれに回答しようとおもいます。みんなもなにかおもうところがあれば、SNSではなくブログにしてほしい。(Webからそのままアクセスできるという点において)

1. 基本方針
2. 仕様化テスト、レガシーコード改善、リファクタリングでつかう
3. トランザクションのcloseなどの後処理を確実に検知する。Rxや一部の書き方によってtry-with-resourcesがつかえなくても。

1. 基本方針

可能なかぎりモックライブラリはつかわず、コンストラクタDI(Dependency Injection)で解決できるならそうする
往々にして厳密な単体テスト(1ファイルにとじたテスト)はしておらずコンポーネントテスト(複数ファイルにまたがったテスト)がおおい

2. 仕様化テスト、レガシーコード改善、リファクタリングでつかう

自動化されたテストがなく、これからリファクタリングをしたいというときには、既存のプロダクトコードを変更せずに自動テストを実装すべきです。そのときには時刻やDBやAPIなどに依存したコードをテストしなければいけないでしょう。

テスタビリティの低い設計ではこれらを「テストから設定」することがむずかしかったり、高速な単体テストとすることがむずかしかったりします。そのときには、モックライブラリをつかって時刻やDBやAPIなどをテストダブル(スタブやモック)におきかえます。

モックライブラリは実質的にリフレクションなどをつかっているものがおおく、プロダクトコードを変更せずにプログラマーが自由なコードで一部の処理を代替させることができます。これによって自動テストを実行できるようにしてから、徐々にリファクタリングをすすめていく。という場面ではモックライブラリが適切でしょう。

3. トランザクションのcloseなどの後処理を確実に検知する。Rxや一部の書き方によってtry-with-resourcesがつかえなくても。

たとえばトランザクションやコネクションのコミットやクローズ処理が確実にされているかを検知したい場合につかえます。単体テストのメリットとして、IO処理が失敗した場合を簡単に模倣できるという点があります。それ自体はコンストラクタDIな設計における簡易なテスト用のスタブクラスでもできます。

ですが、たとえばDB操作が失敗したときに必ずコネクションがcloseされていることのテストはなかなか検知できません。モックライブラリであればできます。もちろん静的コード解析でも対応できる部分はありますので、一概にモックライブラリでやるべきとはいいませんが、なかなかに便利なときがあります。

Javaだとtry-with-resourcesとかでかいておけばいいじゃんというのもありますが、rx系というかpromise系というかのライブラリをつかっていたり、いくつかの設計においてはtry-with-resourcesをうまくつかえないことがあります。そのときには、モックライブラリで検知させるというのは妥当だとかんがえています。