通常のテスト スイートを含むインストール可能な Django アプリを管理しています。
プロジェクト作成者が自分のサイトで実行する場合、当然のことながらmanage.py test、自分のアプリと、私のようなサードパーティがインストールしたアプリの両方のテストがすべて実行されます。
私が見ている問題は、いくつかの異なるケースで、ユーザーの特定settings.pyに、アプリのテストが失敗する原因となる構成が含まれることです。
いくつかの例:
- 一部のテストでは、返されたエラー メッセージをチェックする必要があります。これらのエラー メッセージは国際化フレームワークを使用しているため、サイトの言語が英語でない場合、これらのテストは失敗します。
- 一部のテストでは、特定のテンプレート出力をチェックする必要があります。サイトがカスタマイズされたテンプレート (アプリがサポートする) を使用している場合、テストはデフォルトよりもカスタマイズされたテンプレートを使用することになり、テストは再び失敗します。
これを回避するために、テストを実行する環境を分離するための賢明なアプローチを見つけようとしています。
現時点での私の計画は、すべての TestCase クラスがベースの TestCase を拡張し、設定をオーバーライドすることと、その他の環境設定に注意する必要があることです。
私の質問は次のとおりです。
- これは、アプリ レベルのテスト環境を分離するための最善の方法ですか? 私が見逃した代替手段はありますか？
- 理想的には、おそらく完全にクリーンな構成が必要な場合に、一度にしか設定をオーバーライドできないようです。これを行う方法はありますか?そうでない場合、基本的なクリーンセットアップを行うために確認する必要がある主な設定はどれですか?
INSTALLED_APPSなどの一部の設定をオーバーライドしても、実装の詳細やグローバルな状態の問題により、実際には期待どおりに環境に影響を与えない可能性があると言っているのは正しいと思います。これは正しいです？どの設定に注意する必要がありますか? また、グローバルにキャッシュされた環境情報のうち、期待どおりに影響を受けない可能性があるものはどれですか?- 設定以外にクリーンであることを確認する必要がある環境の状態は何ですか?
より一般的には、これが他のサードパーティのインストール可能なアプリにとってどの程度の問題であるか、またはコアでこれらのいずれかにさらに対処する計画があるかどうかに関するコンテキストにも興味があります. たとえば、IRC で同様の問題に関する会話を見てきました。予期しない設定構成で実行されている Django の contrib アプリの一部。私もサードパーティのアプリと django contrib アプリの両方で同様のケースに何度か遭遇したことを覚えているようです。より多くの作業が必要な場合、または現状で十分である場合。
ご了承ください：
- これらは統合レベルのテストであるため、グローバル レベルでこれらの環境問題に対処したいと考えています。
- Django 1.3 をサポートする必要がありますが、大量の Django コードを再実装しない限り、いくつかの互換性ラッパーを入れることができます。
DJANGO_SETTINGS_MODULE明らかに、これはインストール可能なアプリであるため、テストに使用する独自のアプリを指定することはできません。