Welcome to the pain that third party app maintainers have already been dealing with for the past year. I ran into this problem as well when I added custom user support to one of the apps I maintain. As you noted you can't simply change the AUTH_USER_MODEL setting because once the test DB is created the FK references are set. The only solution I found was to use tox (which I was already using to test versus multiple Python/Django versions) and run the full suite once with the standard user model and again with a custom user model. Some tests are skipped when the default user is used and others are skipped with the custom user is in use. You can see it in action here: https://github.com/mlavin/django-all-access
I'd love to see a more general solution to this but I have a feeling anything that attempts to modify the DB tables between tests is destined to fail. Best, Mark On Wednesday, February 26, 2014 2:33:24 AM UTC-5, Russell Keith-Magee wrote: > > Hi all, > > tl;dr; I've been working on a last little feature for 1.7 - an email-based > User model for contrib, but I need some help/guidance on the last step - > getting the tests working. > > The idea here is that we just ship a normal auth.User, but with email > identification rather than username. This is essentially the 80% case for > requests for custom User models anyway, and it provides an example of "how > to do it" for anyone that wants to follow the lead. > > I've also taken the opportunity to do a bit of refactoring of auth forms > and the AbstractUser to make re-use of common parts a bit easier. > > Code is available here. Other than bikeshed stuff (name of module, name of > classes etc) it shouldn't be too controversial: > > https://github.com/freakboy3742/django/tree/emailauth > > There are two things still pending on this patch: > > 1) Documentation. There isn't much to document, but obviously this is > required. > > 2) Tests that work. > > It's the second point where I need some assistance (or at the very least, > some suggestions of directions I can go with this). > > There isn't that much that requires testing -- after all, it's a fairly > vanilla User model. A bit of light testing of forms, some checks to make > sure that the models can be created, and that they play well with > ModelBackend, and so on. > > However, there's a problem with including these tests as part of Django's > own testing infrastructure, due to clashes with Django's default User model. > > In a production app, you either want a normal Django User model, in which > case you don't include contrib.emailauth in your app; or you include > contrib.emailauth, and you set AUTH_USER_MODEL must be set (I haven't added > a formal check for this, but I could). As a result, there's no confusion > over which User model is active. I've done some manual testing, and the > user model all works as expected. > > While running Django's test suite, however, the suite installs both > contrib.auth and contrib.emailauth, but *doesn't* set AUTH_USER_MODEL to > emailauth -- it can't, because we need to test default User behaviours. > > Both auth.User and emailauth.User have relations with Group, and the names > clash, so the test suite won't start. > > If you deliberately silence the model integrity system checks, you get > other errors, caused by the fact that there's confusion over which > AUTH_USER_MODEL is active at any given time. > > So - I'm looking for suggestions for how this can be handled in Django's > test suite. > > I've thought about explicitly excluding contrib.emailauth from the test > suite's INSTALLED_APPS, but then the tests in emailauth don't get > discovered and executed. > > Even if you reorganise the tests to make them part of the "django" tests, > rather than tests that are part of the contrib app, you get problems > because you end up with two models with the same relation name to Group. > > So - anyone got any ideas how to handle this? Is there some feature of the > new app loading code that I can exploit here? > > Yours, > Russ Magee %-) > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a3259799-00a4-432c-ab59-d0401c44625e%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
