TDDでデータベースと付き合う方法

はじめに データベースを読み書きする部分のユニットテストがやりにくいのには、いくつか理由があります。 複数人でテストを同時に実行すると、競合する データベースを使ったテストは、時間が掛かる データベース内のデータが変わると、テストが失敗する 1番目は、各自の開発環境にテスト用のデータベースを用意することで、解決できます。2番目の問題は、データベースにアクセスするコードをロジックから分離して、データベースに実際にアクセスするテストケースを減らすことで、改善できます（ロジックのテストにはモックやダミーを使います）。3番目は、テストのたびにデータベースの内容を初期化することが基本になりますが、そうするとテストに長い時間が掛かるようになってしまいます。 今回は、ビジネスロジックの開発時にモックやダミーを使いやすくするにはどうするか、また、テスト時にデータベースの内容を安定させるにはどうしたらよいか

[SWIMATH2]

まあ分かるって感じもする

[beatdjam]

*Test

[msykxxx]

読む

[ryuzee]

分かりやすい！（けど製品コードの日本語関数名とかはイヤ...)

[iww]

テスト用DBを毎回作るんじゃないのか。

[kaji_3]

いつも挫折するデータベース周りのテストコードの書き方がバッチリまとまっていて勉強になります！

[JHashimoto]

"製品コード側でデータベースに変更を加えてコミットしても、その後でユニットテスト側でロールバックしてしまえば、データベースにはまったく変更が残りません。"