可定製的Authencation後端沒有跟在Django自己的登錄測試用例之後。爲什麼？

我瞭解到，使用Customizable Authencation backends philosophy，可以創建一個接受電子郵件地址作爲用戶名的網站。但是在構建相應的邏輯並測試我的代碼工作正常後，我發現Django自己的測試用例存在一個問題。他們沒有遵循Customizable Authencation後端哲學。意思是，用於測試「登錄」過程的測試用例were actually having hardcoded values('username': 'testclient')。這是爲什麼？ Django總是不鼓勵緊密耦合。但是這裏發生了什麼？可定製的Authencation後端沒有跟在Django自己的登錄測試用例之後。爲什麼？

我不會用任何方式抨擊Django！我是一個很大的粉絲，我會在未來數年內。只是想知道這背後的原因！

更新：由於@dmishe指出那些測試用例應驗證Django自己的功能。我明白。但是，當我運行測試用例或運行整個項目測試套件時，如何讓那些「失敗的測試用例」錯誤不顯示？

來源

2010-01-28 None-da

我認爲這個問題在django郵件列表上更合適。這裏的任何答案都是猜測，除非你得到公平參與項目的人的回答（當然這完全有可能） – 2010-01-28 22:14:54

正如dmishe指出的那樣，contrib.auth測試測試內置於contrib.auth應用程序的功能並不是問題。這是一個問題，默認情況下，這些測試是針對用戶項目運行的，並且很容易通過正常的設置自定義來破壞它們。這是Django開發人員意識到的問題，並正在研究可能的解決方案。

與此同時，我的解決方案是定義一個簡單的bash腳本來僅測試我想要的應用程序。所以，而不是「./manage.py測試」我運行一個腳本，「./manage.py測試app1 app2 app3 ...」。不完美，但它遠離我的最壞的問題:-)

更新：This commit可能會讓你感興趣。

來源

2010-01-29 17:11:17

我希望用unittest套件來解決這個問題。但是，它仍然需要app1，app2，app3提及的場景。所以現在我會繼續這樣做。但等待更好的解決方案.... – 2010-02-12 19:09:13

@Carl謝謝你的建議。我通過覆蓋settings.INSTALLED_APPS嘗試了相同的方法，並從settings.INSTALLED_APPS中移除了django.contrib.auth（用於繞過「auth」測試）。它導致不創建「auth_user」表，這是我所有其他測試所需的表。所以沒有運氣:( – 2010-02-14 07:11:22

我在這裏沒有看到問題，django.contrib.auth.tests應該測試身份驗證應用程序，僅此而已。因此，它應該測試作爲用戶名/密碼組合的內置後端。

來源

2010-01-28 22:24:50

@dmishe！你是對的。我越想它，我越傾向於發現它，它其實是真的。但是當我運行我的測試用例時，我不能期待Django的測試用例失敗。那麼是否有一個可行的解決方案/解決方法來繞過這個問題？ – 2010-01-29 03:05:04

可定製的Authencation後端沒有跟在Django自己的登錄測試用例之後。爲什麼？

回答

相關問題