管理Django的測試隔離安裝應用程序

我保持一個可安裝的Django應用程序，包括定期測試套件。管理Django的測試隔離安裝應用程序

很自然，當項目運行作者爲manage.py test他們的網站，對於自己的應用，並還安裝任何第三方應用程序，如煤礦將全部運行測試。

是我看到的問題是，在幾個不同的情況下，用戶的特定settings.py將含有導致我的應用程序的測試失敗配置。

幾個例子：

有些測試需要檢查返回的錯誤信息。這些錯誤消息使用國際化框架，所以如果網站語言不是英語，那麼這些測試失敗。
某些測試需要檢查特定的模板輸出。如果網站使用自定義模板（應用程序支持），那麼測試將最終使用自定義模板而不是默認模板，並且測試將再次失敗。

我想試圖找出一種明智的方法來隔離我的測試運行的環境，以避免這種情況。

我現在的計劃是讓我所有的TestCase類擴展一個基本的TestCase，其中包括overrides the settings以及其他我需要照顧的環境設置。

我的問題是：

這是應用級的測試環境隔離的最佳途徑？有沒有我錯過的選擇？
它看起來像我只能覆蓋在時間設置，當理想我可能會像一個完全乾淨的配置。有沒有辦法做到這一點，如果不是，我需要確保設置的主要設置是爲了有一個基本的乾淨設置？
我相信我在說一些覆蓋等設置INSTALLED_APPS可能無法以預期的方式在環境實際影響，由於實施細則，以及全局狀態的問題是正確的。它是否正確？我需要注意哪些設置，以及全局緩存的環境信息可能不會像預期的那樣受到影響？
我可能需要比設置什麼其他環境狀態等，以確保是否乾淨？

更一般地說，我還會對任何有關其他第三方可安裝應用程序問題的情況感興趣，或者有任何計劃在覈心中進一步解決這些問題。我曾在IRC上看到有關類似問題的談話。一些Django的contrib應用程序在意外的設置配置下運行。我似乎還記得幾次遇到類似的情況下與第三方應用程序和Django的貢獻應用程序，所以感覺我並不孤單面對這些問題，但不清楚是否有共識，如果這是需要更多工作或現狀足夠好的東西。

需要注意的是：

這些集成級別的測試，所以我想在全球範圍內解決這些環境問題。
我需要支持Django 1。3，但只要我不重新實現大量的Django代碼，就可以放入一些兼容性包裝器。
很明顯，因爲這是一個可安裝的應用程序，我不能指定我自己的DJANGO_SETTINGS_MODULE用於測試。

來源

2012-10-24 Tom Christie

一個很好的方法來隔離我見過使用Jezdez是有一個叫做my_app.tests子模塊包含了所有的測試代碼（example）。這意味着當有人安裝你的應用程序時，這些測試不會默認運行，所以他們不會得到隨機的幻像測試失敗，但是如果他們想檢查它們沒有無意中破壞什麼，那麼就像將myapp.tests添加到INSTALLED_APPS讓它運行。

在測試中，您可以盡最大努力確保使用override_settings（如果不在1.4中，那麼沒有太多的代碼）存在正確的環境。就我個人而言，我的感覺是，在集成類型測試中，如果它們失敗，也許並不重要。如果你喜歡，你可以包含一個乾淨的設置文件（compressor.test_settings），這對於一個主要項目來說可能更合適。

另一種方法是將測試分開 - 對於contrib.admin，django.contrib.admin.tests和tests.regression_tests.contrib.admin（或類似的路徑）有兩個單獨的測試體。那些檢查公共apis和核心功能（應該）的應用程序駐留在第一個中，並且任何可能被其他人（合理）配置中斷的任何內容都駐留在第二個中。

恕我直言，整個運行外部應用程序測試是完全破碎。它肯定不應該在默認情況下發生（並且有討論），它甚至不應該是一件事 - 如果某人的外部應用程序測試套件被我的猴子修補程序（或其他）所破壞，我實際上並不關心 - 我絕對不希望它打破我的網站的構建。也就是說，上述方法允許那些不同意的人很容易地運行它們。 Jezdez可能擁有和其他人一樣多的主要可插入應用程序，即使他的方法存在一些微妙的問題，至少也存在行爲的一致性。

來源

2012-10-24 11:16:59 mjtamlyn

美麗的做法，謝謝！ – sleepycal