Mockを使ったテスト or DB依存テスト

　日常ではない日記です。技術的なことはZennに書くようにしているけれど整理できていないので日記として残しておく。

　以前携わったプロジェクトではDB依存テスト大量に書いていました。なぜかというと、ORMが多機能かつ歴史がながく情報が新旧入り乱れていたため、ORMをつかったコードが本当に望んだとおりのSQLを実行してくれるのか確信がもてなかったからです。そこで、まずは本番に近いダミーデータを大量につくり（ここは後輩にすごく頑張ってもらった🙏）、それを正しく絞り込めているか確認する必要がありました。その結果、単体テストの8割はDBに依存したテストになってしまました。そしてMockをつかったのはエラーケースをテストするときくらいだったと思います。

　さて直近の開発はというとMockを多用して開発しています。これはDBに対するCRUD処理に一定の自信がある（or 切り分けができている）からなせることだと思っています。「DBを正しく操作できている」と仮定できれば、Mockで固定値を返すテストを増やしていけます。Mockの良い所は色々な値を即席で返せるところです。新しい値を試すために毎回DBに入れる必要もありません。テスト用データの肥大化も防げます。

　DBに対するCRUD処理に対する自信は生産性やテスト拡充に大きな影響を与えるなと感じるこのごろです。ORMを使ったDB処理ををRepositoryに集約して集中的にテストするなど回避する方法はあったかもしれませんが、そうするとそうとうFatなRepositoryになっていた気もします。

　ORMが悪いわけではないのですが、高機能なORMは学習コストが非常に高いです。ORMを用いて意図したSQLを自在に生成できるようになるまでには、かなりの時間を要することを肝に銘じておかないと痛い目みるぞという学びでした。