なぜこれが私に起こったのか、そして上記のIlyaBaryshevの答えを含むいくつかの可能な回避策を見つけました。
テストがDjangoの子孫TestCase
であり、データベースがトランザクションをサポートしている場合、各テストは独自のトランザクションで実行され、外部の誰も(他のスレッド、外部プロセス、または他のテスト)、テストによってデータベースに作成されたオブジェクトを見ることができません。
LiveServerTestCase
スレッドを使用するため、この問題が発生します。そのため、設計者は、変更がグローバルに表示されるように、これらのトランザクションを無効にするTransactionTestCase
のではなく、から継承するようにしました。TestCase
私に起こったことは、テストクラスにいくつかのミックスインを追加し、そのうちの1つをプルインしたことTestCase
です。これによってエラーが発生することはありませんが、の基本クラスがにサイレントに置き換えLiveServerTestCase
られTestCase
、トランザクションが再び有効になり、説明した問題が発生します。
IlyaのSQLiteメモリデータベースの回避策は:memory:
、スレッド間で実際に同じ接続を共有するSQLiteデータベースを使用するときに検出するコードがDjangoに含まれているために機能します。したがって、テストのオブジェクトは同じトランザクションLiveServerThread
内にあるため、に表示されます。ただし、これにはいくつかの注意点があります。
2つのスレッドによるこの共有接続を介したデータベースクエリの同時発生を防ぐことが重要です。これにより、テストがランダムに失敗する場合があります。したがって、2つのスレッドが同時にデータベースにアクセスしないようにする必要があります。特に、これは、場合によっては(たとえば、リンクをクリックした後やフォームを送信した直後)、Seleniumが応答を受信し、次のページが読み込まれたことを確認してから、さらにテストを実行する必要があることを意味します。これを行うには、たとえば、応答でHTMLタグが見つかるまでSeleniumを待機させます(Selenium> 2.13が必要です)...
https://docs.djangoproject.com/en/1.4/topics/testing/#live-test-server
私の場合、autocommit
テストの開始時にオフになっていた識別子を特定し、その理由を突き止めたら(TestCase
実行すべきでないコードを入力したため)、継承階層を修正して、プルインを回避することができましたTestCase
。次に、ライブサーバースレッドとテストの両方から同じデータベースが表示されました。
これはPostgresデータベースでも機能するため、velotronのソリューションを提供します。