Django アプリケーションをテストするために作成した単体テストがいくつかあります。特に 1 つのテスト スイートには、そのsetUp()機能に多くのコードが含まれています。上記のコードの目的は、データベースのテスト データを作成することです。(はい、私はフィクスチャについて知っており、この場合は使用しないことにしました)。単体テスト スイートを実行すると、実行された最初のテストは成功しますが、スイート内の残りのテストは失敗します。すべての失敗のメッセージは同じです。エラーの場所は「self.database_object.save()」であり、原因は「IntegrityError: 列名が一意ではありません」であることが示されています。したがって、私の推測では、Django は各テストの後でデータベースを適切に分解していないということです。
今日の初めは機能していましたが、私が行ったリファクタリングで台無しになったと思います。各テストの後に Django がデータベースを適切に破棄しない理由について何か考えはありますか?
基本クラスに TestCase または TransactionTestCase を使用していますか? この動作は、Django が TransactionTestCase を優先して TestCase に対して行う最適化に関連している場合があります。違いは次のとおりです。
https://docs.djangoproject.com/en/dev/topics/testing/?from=olddocs#django.test.TransactionTestCase
クラス TransactionTestCase
Django TestCase クラスは、データベース トランザクション機能が利用可能であればそれを利用して、各テストの開始時にデータベースを既知の状態にリセットするプロセスを高速化します。ただし、この結果として、トランザクションのコミットとロールバックの効果を Django TestCase クラスでテストすることはできません。テストでこのようなトランザクション動作のテストが必要な場合は、Django TransactionTestCase を使用する必要があります。
TransactionTestCase と TestCase は、データベースを既知の状態にリセットする方法と、テスト コードでコミットとロールバックの効果をテストする機能を除いて同じです。TransactionTestCase は、すべてのテーブルを切り捨てて初期データをリロードすることにより、テストを実行する前にデータベースをリセットします。TransactionTestCase は commit と rollback を呼び出し、これらの呼び出しがデータベースに与える影響を観察します。
一方、TestCase は、テーブルを切り捨てたり、テストの開始時に初期データをリロードしたりしません。代わりに、テストの最後にロールバックされるデータベース トランザクションにテスト コードを含めます。また、テスト中のコードがデータベースに対してコミットまたはロールバック操作を発行するのを防ぎ、テストの最後のロールバックによってデータベースが初期状態に確実に復元されるようにします。すべての TestCase コードがクリーンなデータベースで開始されることを保証するために、Django テスト ランナーは最初にすべての TestCase テストを実行し、データベースを元の状態に復元せずにデータベースを変更する可能性のある他のテスト (doctest など) よりも先に実行します。