Tweet
Tweet

Slide 1

Slide 1 text

DBアクセスを伴う結合テストを 書くときのプラクティス BABY JOB株式会社 第8回社内LT 2024/09/26 西牧 佑哉

Slide 2

Slide 2 text

大事なこと ● テストの環境を本番とできるだけ合わせる ○ テストの環境が本番と違っていると結果を信頼しづらくなる 2


Slide 3

Slide 3 text

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


Slide 4

Slide 4 text

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


Slide 5

Slide 5 text

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


Slide 6

Slide 6 text

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


Slide 7

Slide 7 text

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


Slide 8

Slide 8 text

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


Slide 9

Slide 9 text

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


Slide 10

Slide 10 text

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


Slide 11

Slide 11 text

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


Slide 12

Slide 12 text

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


Slide 13

Slide 13 text

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


Slide 14

Slide 14 text

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


Slide 15

Slide 15 text

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


Slide 16

Slide 16 text

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