Django'；后面没有可定制的Authencation后端；用户自己的登录测试用例。为什么？

我学会了使用，一个人可以创建一个网站，接受电子邮件地址作为用户名。但是在构建了相应的逻辑并测试了我的代码是否正常工作之后，我发现Django自己的测试用例存在一个问题。他们没有遵循可定制的Authencation后端理念。也就是说，测试“登录”过程的测试用例。为什么呢？Django总是不鼓励紧密耦合。但是这里发生了什么

我不是在用任何方式攻击Django！我是一个超级粉丝，在未来的几年里，我也会是。只是想知道这背后的原因

---

更新：正如@dmisher指出的，这些测试用例应该验证Django自己的功能。我明白这一点。但是，当我运行我的测试用例或运行整个项目测试套件时，如何让那些“失败的测试用例”错误不出现？

我看不出有什么问题，django.contrib.auth.tests应该测试auth应用程序，仅此而已。因此，它应该测试内置后端，即用户名/密码组合。

正如Dmisher指出的，contrib.auth测试contrib.auth应用程序内置的功能不是问题。默认情况下，这些测试是为用户项目运行的，这是一个问题，通过常规设置自定义很容易破坏它们。这是Django开发人员意识到的一个问题，他们正在研究可能的解决方案

同时，我的解决方案是定义一个简单的bash脚本，只测试我想要的应用程序。因此，我运行的脚本不是“/manage.py test”，而是“/manage.py test app1 app2 app3…”。不完美，但这远不是我最糟糕的问题：-）

---

更新：您可能会感兴趣。

我认为这个问题在django邮件列表中更合适。这里的任何答案都是猜测，除非你从参与该项目的人那里得到答案（这当然是完全可能的）@dmishe！你是对的。我想得越多，我就越倾向于发现这是真的。但是当我运行我的测试用例时，我不能期望Django的测试用例失败。那么，是否有一个可行的解决方案/解决方法来绕过这个问题呢？我希望通过unittest套件来解决这个问题。但它仍然需要上述场景中的app1、app2、app3。所以现在我要说这个。但是等待更好的解决方案…@Carl谢谢你的建议。我通过覆盖settings.INSTALLED_APPS尝试了相同的方法，并从settings.INSTALLED_APPS中删除了django.contrib.auth（用于绕过“auth”测试）。它导致没有创建“auth_user”表，这是我所有其他测试所需要的。所以没有运气：(