#17966: Tests fail with trivial usage of AUTH_PROFILE_MODULE
------------------------------+------------------------------------
Reporter: slacy | Owner: nobody
Type: Bug | Status: new
Component: contrib.auth | Version: 1.4
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
------------------------------+------------------------------------
Comment (by rob@…):
Replying to [comment:14 carljm]:
> Replying to [comment:13 SamBull]:
> > Replying to [comment:12 aaugustin]:
> > > Replying to [comment:10 SamBull]:
> > > > Is there a workaround for this issue? It's preventing us from
migrating to 1.4 because our deployment system won't let us push out a
release with failing tests.
> > >
> > > You should only test your own apps, not Django's contrib apps:
`./manage.py test myapp1 myapp2 ...`
> >
> > Huh. That's not true is it? Some of django's tests are integration
tests that help us verify that we're using everything correctly (providing
essential templates, settings, etc.).
>
> That was the theory at one time, but it doesn't work very well in
practice. There are so many ways to integrate contrib or other third-party
apps, oftentimes with customizations, wrapped views, etc., and it's almost
impossible for a reusable-app author to write tests that will reliably
pass with all functional customized integrations. Over time, as "failing
test" reports (just like this one) come in against contrib apps and are
fixed, the tests become more and more isolated from the settings of the
project they are running in (provide their own templates, temporarily
override settings to known values, etc), and eventually lose any value
they may have once had as integration tests.
>
> Fundamentally, integration tests are the responsibility of the
integrator, who is the only party who knows how their specific integration
is supposed to work.
>
> For Django 1.5 it is likely that the default test runner will not run
tests from external apps by default. So yes, I would say that changing
your continuous integration tests now to match that practice would be
sensible, and I don't believe that in practice you'll lose significant
value in terms of coverage of your code and settings.
I find that often the strange edge-cases are caught by running the tests
in contrib, which my own tests may not necessarily cover (though this
should obviously be rectified, if such a situation is discovered).
For example, the behaviour of custom middleware on login/logout views. I'd
feel somewhat uncomfortable excluding Django's tests from the build (is
there even a way to do this - or must you specify each of your own apps
explicitly on the command line?)
--
Ticket URL: <https://code.djangoproject.com/ticket/17966#comment:15>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
