外部キー制約が関わるテストについて

Question

とあるテーブル(仮にA)のデータを削除しテストデータを追加してから、テストをしたいと思っています。

その際に、Aに対して外部キー制約を張っているテーブルBがいます。
Bの制約でAのデータを削除できません。

このような場合、みなさんはどのようなアプローチをとられますか？

思いつくところだと、テスト前にBの制約を外しテスト後に制約を付け直すです。
ただし、制約が複数ついたテーブルは、大変かなという気持ちです。

なにか良い方法があればアイディアお願いします。

Answer 1

テスト駆動開発とあるので、ユニットテストツールを使ってテストしている前提で話をします。

私がテストする場合は、空のテーブルを使うのが基本なのでこの手のものだいは起こらないことが多いです。

ユニットテストでは、実行されるテストの順序が変わったりテストを削除したりするとテスト結果が変わってしまうのを避けるために、個々のテストでテストデータは作り直すことが推奨されます。そのため、ponzuさんの環境は、ユニットテストには向いていないかもしれないと考えています。

テスト用のＤＢインスタンスは用意できていますか？できていないなら、是非用意してください。リグレッションテストとは違い、データ量は少ないので、作れない理由はあまりないと思います。

テストケース毎に、テストデータを作り直すということからわかると思いますが、ユニットテストでＤＢを使っていると結構重くなってしまいます。テスト駆動開発の場合、テストの回数はかなり多いので、実行速度はかなり重要になります。オブジェクトのCRUDのテストはともかくとして、ロジックのテストであれば、モックオブジェクトなどを使って、ＤＢアクセスを抑えるのも良い方法です。

Answer 2

これはテストの内容に依ると思います。

例えば、
Aについての単体テスト
「Bの制約」についても試験対象
によって変わってきます。

意見が割れる、というよりは「条件が固まっていない」ことが悩む要因だと思います。仰る通り、「BのみでなくC、D・・・と複雑な依存関係の場合」も考えられますし、逆に「Aが単独で非常に大きく、Bの制約の方を直したほうが楽」ということもありえます。

Answer 3

Bも消せばいいんじゃ?

Comments

[ponzu_647]

なるほど、Bを消してしまいテスト後に作り直すというのは、状態を管理しなくなるので良さそうですね。