Repositoryのtest





transactionをUnit Of Workに変換する
これは実装部分の話

1つのtest case内のAAAパターンの異なるフェーズで、同じtranscationやUnit Of Workを使い回さない
どういうこと？
なぜ？






殆ど、データ整形しか無い場合はテストの必要性をそもそもあまり感じないmrsekut
テストの要件が見えていない
何をテストすればいいのかがわからない
DBの内容がおかしいことのテストとか？
Repositoryがcacheを管理しているときは、cacheのテストとかか
cacheにデータが有ればそれを返して、なければどこかから取ってくる、とか
getUserById(number) とかで、ちゃんとuserが返ってくるかとかか
DBもdummyであってほしい
SQLは仕様の列挙が型でできないので、仕様の列挙のためにも、Repositoryのtestがほしいmrsekut
SQLの正当性のtest
この場合に、実際のDBを見てテストするのか、
この場合、ciなども鑑みて、その環境を簡易に作れるようにしておく必要がある
モック的なものを用意すればそれで済むのか
モックを用意する場合どのように用意するのか



repository層をmockする
これはrepositoryに依存するものをテストする時の話なので、このページには関係ない
with Prisma
mockを使わないテスト
>@t_wada: データアクセスレイヤのテストを書く際にDBをモックするのは自作自演のテストになりがちなので個人的にはおすすめしません / “Prisma で本物のDBMSを使って自動テストを書く - mizdra's blog” https://t.co/3YIcK3ptU9
Prisma
実際のDBと通信してテスト






Related