DBアクセスを伴う自動テストを書くときのプラクティス/Practices When Writing Automated Tests with DB Access

Transcript

1. DBアクセスを伴う結合テストを 書くときのプラクティス BABY JOB株式会社 第8回社内LT 2024/09/26 西牧 佑哉
2. 大事なこと • テストの環境を本番とできるだけ合わせる ◦ テストの環境が本番と違っていると結果を信頼しづらくなる 2

3. テスト用DBのスキーマファイルを手動で管理しない 3

4. 想定しているケース • DBの変更履歴をマイグレーションファイルで管理している • テスト用DBのセットアップのためにスキーマファイルを用意している 4

5. 手動管理のデメリット • マイグレーションファイルの内容に合わせて変更するのが面倒 • ミスがあっても気づきづらい 5

6. どうするか？ • スキーマファイルを用意しない ◦ テスト実行前にマイグレーションする • 自動生成する（ダンプする） ◦ マイグレーションに時間がかかる場合に有効 ◦ マイグレーション後に必ずスキーマファイルが生成/更新される仕組みにしておくと常に最新 に保てる 6

7. インメモリDBを使用しない 7

8. 想定しているケース • ローカルではDockerで立てたDBを使用して開発している • テストではSQLiteやH2のようなインメモリDBを使用している 8

9. インメモリDBを使用するメリデメ • メリット ◦ セットアップが簡単 • デメリット ◦ 本番環境やローカルでの動作確認時と異なる挙動をする可能性がある ▪ つまり、テスト結果を信頼しづらい 9

10. どうするか？ • ローカルや本番と同じDBを使用する ◦ Testcontainersを使うと簡単にできる！ 10

11. テストの準備、実行、検証を 同一トランザクション上で行わない 11

12. 想定しているケース • テスト実行時の挙動 1. トランザクション開始 a. 準備（テスト用のデータのインサート） b. 実行（例：何らかの保存処理） c. 検証（例：DBからデータを取得して保存した内容の確認） 2. ロールバック 12

13. 同一トランザクションで行うメリデメ • メリット ◦ テスト終了後にロールバックしてテストデータの後始末ができる • デメリット ◦ 本番では準備、実行、検証が同一トランザクション上で行われない ▪ つまり、テストと本番でやっていることが異なる 13

14. どうするか？ • 各フェーズごとにトランザクションを分ける • テストデータの後始末はテスト前に行うようにする ◦ 他のテストに依存せずに、確実にクリーンアップできる 14

15. 参考 • 単体テストの考え方/使い方 15

16. まとめ • テスト用DBのスキーマファイルを手動で管理しない • インメモリDBを使用しない • テストの準備、実行、検証を同一トランザクション上で行わない 16