DB のモックとテスト

TDD とライオンで著名な t-wada さんがこんなツイートをしていた。

データアクセスレイヤのテストを書く際にDBをモックするのは自作自演のテストになりがちなので個人的にはおすすめしません / “Prisma で本物のDBMSを使って自動テストを書く - mizdra's blog” https://t.co/3YIcK3ptU9

— Takuto Wada (@t_wada) November 24, 2022

ツイートで引用していた記事の内容を読んだ上で、データアクセスレイヤに対するテストについて自分なりの考えを書いてみる。 データアクセスレイヤは ActiveRecord のような O/R マッパだったり、リポジトリパターンを用いたようなクラスかもしれない。ここは各々のプロジェクトによって異なる。

データアクセスはアプリケーション独自の実装になるので、自分はモックせずにテストを書く価値があると思っている。例えば ID からレコードを取得する、指定された条件のレコードのみ取得するといった実装に対するテストは、その条件を満たすクエリを正しく発行していることが保証できるので安心感が増す。

対して、データアクセスレイヤのテストでモックすると条件に合ったクエリが発行されているかなどは無視されてしまい、条件を満たしているであろう値をそれっぽく返してとりあえずパスしてしまい、果たしてこれはテストコードなのか…？　となってしまう。モックはコードの実行結果を書き手が指定するもので、テストはコードの実行結果を評価するものと解釈すると自作自演のテストと言われるのがしっくりくるなーと思った。

どこからモックするかは規模やチームによっても異なるので解が 1 つに定まることはないと思う。データアクセスレイヤに対するテストが書けているなら依存している別レイヤではモックしてしまってもいいのかなーというのが個人的な意見。別のレイヤではそのレイヤでの実装に対してテストを行いたいはずなので。

余談だけどデータアクセス周りはセットアップとティアダウンも悩みどころだなーと思う。手間を減らすとか Flaky Test にならないようにするとか考えてヘルパーを作るのって難しい。