Prisma で本物のDBMSを使って自動テストを書く - mizdra's blog

DBMS に依存するロジックのテストを書く時、主に2つの手法があると思います。 Repository 層などを mock する Service 層のテストをする時は、その下位の Repository 層を mock して、DBMS に依存しない形にしてからテストする レイヤードなアプリケーションで適用できる手法 テスト実行時も DBMS を裏で動かして、それを使う 本番と同じスキーマを持つ DBMS に対して、実際に insert したり select してテストする DBMS は docker-compose upとかで事前に立ち上げておく 双方にそれぞれ良さがあって、プロダクトによってどっちでやるか変わってくると思います。 この記事では 2 の手法を Prisma でどうやるかについて紹介します。 前提 実際のテストコードの例 テストヘルパーを作る 別解: ヘルパーを自動生成する je

[t-wada]

データアクセスレイヤのテストを書く際にDBをモックするのは自作自演のテストになりがちなので個人的にはおすすめしません

[send]

極力 mock は使いたくない派(つい手を抜いて t-wada の言うところの "自作自演のテスト" にしてしまいがちなので)

[sigwyg]

データアクセスのテストなら実DB使いたいよなーと。Serviceとかは別の責務があるから、モックで良いのでは派

[kazokmr]

TestContainersでPostgreSQLのコンテナを立ち上げてrepositoryクラスのユニットテストとか結合テストに使ったことはある。Serviceクラス自体のテストだとrepositoryはmockにしちゃうな

[turanukimaru]

java というか Spring では DB のテストは本物のまっさらDBにテストデータを投入してSQLを実際に投げるテストをする。Mockはテストのためにしょうがなく用意するものでMockを使うか使わないかはテストしてる対象が違う。

[ryousanngata]

DB依存のテストはセットアップが面倒だったり遅いので、リポジトリ層やトリガーなどのテストのみに留めて極力避けるが、受け入れとかでは一連のフローで書く時もある。

[taruhachi]

本物のDBMSを使う方法で、巨大なテーブルを持つ論理DB（※負荷試験用）と共存している環境のテストで、どんな小さなテーブルでもtruncateが非常に遅くなりテスト実行時間が爆発したことがあるので知見共有まで。

[n314]

リポジトリのモック作ってみたけど面倒なのでやめた。そうすると、結局RailsみたいにDBごちゃ混ぜで依存関係を逆転させずにインターフェースも使わない方が楽でバグも少ないのでは…ってなってる。

[shingo-sasaki-0529]

依存性逆転な設計にしてテストではテスト用の Reposity 使うのが良いんだろうなぁとか燻ってたけど、なんかこれ見てたら普通に postgres 起動しちゃって良い気がしてきた。

[ryosuke-fujii]

モックはできるかぎり使わない派

[cateiru]

“queryRaw`SET FOREIGN_KEY_CHECKS”

[onk]

DB 使う以外の選択肢があるのにビックリしている （ある程度 (結構大きいよ) 以下なら本物以外の選択肢が無い

[hitode909]

個人的には、上位層から作っていきたいと思ったことがあまりなくて、必ず下から作っていってる気がする

[w1234567]

DBの規模と開発体制によるな、既存のテストデータが残念で化け物みたいなVIEWやSELECT文でデータ取得してたり複雑なデータ設定が必要だったりするとモック使わないとやってられんわってなる

[ssig33]

Rails 使ったら?