Repositoryのtest
from Repository
Prismaのtest
/mrsekut-book-4839981728/344 (第10章 データベースに対するテスト)
#WIP
/mrsekut-book-4839981728/359
transactionをUnit Of Workに変換する
これは実装部分の話
/mrsekut-book-4839981728/362
1つのtest case内のAAAパターンの異なるフェーズで、同じtranscationやUnit Of Workを使い回さない
どういうこと?
なぜ?
Testcontainers
殆ど、データ整形しか無い場合はテストの必要性をそもそもあまり感じないmrsekut.icon
テストの要件が見えていない
何をテストすればいいのかがわからない
DBの内容がおかしいことのテストとか?
Repositoryがcacheを管理しているときは、cacheのテストとかか
cacheにデータが有ればそれを返して、なければどこかから取ってくる、とか
getUserById(number)とかで、ちゃんとuserが返ってくるかとかか
DBもdummyであってほしい
SQLは仕様の列挙が型でできないので、仕様の列挙のためにも、Repositoryのtestがほしいmrsekut.icon
SQLの正当性のtest
この場合に、実際のDBを見てテストするのか、
この場合、ciなども鑑みて、その環境を簡易に作れるようにしておく必要がある
モック的なものを用意すればそれで済むのか
モックを用意する場合どのように用意するのか
SQLのtest code
repository層をmockする
これはrepositoryに依存するものをテストする時の話なので、このページには関係ない
test時にDBMSを動かす
https://www.mizdra.net/entry/2022/11/24/153459
with Prisma
mockを使わないテスト
@t_wada: データアクセスレイヤのテストを書く際にDBをモックするのは自作自演のテストになりがちなので個人的にはおすすめしません / “Prisma で本物のDBMSを使って自動テストを書く - mizdra's blog” https://t.co/3YIcK3ptU9
dockertest
https://quramy.medium.com/integrated-testing-with-prisma-4bc73404d027
Prisma
実際のDBと通信してテスト
https://zenn.dev/takepepe/articles/nextjs-testing-strategy-2022
APIのtest