On Mon, Jul 13, 2009 at 12:55 AM, Karen Tracey<kmtra...@gmail.com> wrote: > On Sun, Jul 12, 2009 at 8:03 AM, James Bennett <ubernost...@gmail.com> > wrote: >> >> [snip a bunch] >> Similarly, contrib.admin -- because it needs to work out-of-the-box >> without requiring you to create any templates -- supplies templates >> with the names contrib.auth looks for. But you can just as easily >> write your own templates with the correct names, and for public-facing >> authentication functions (i.e., admin, password change, etc. for >> non-admin users) you are encouraged to do so (and if you do the tests >> will pass). >> >> Perhaps a deeper issue is that not every Django application is >> required to ship with default templates. Personally, I like that -- >> making truly generic default templates which can drop into any site >> and be acceptable is a pipe dream. The admin gets away with it because >> the admin isn't meant to fit in with the public-facing look and feel >> of anyone's site. But contrib.auth can't generically do this because >> you typically do want those views to end up fitting the public-facing >> look and feel of your site. > > I think the problem we have right now is we haven't made a consistent > decision on whether the auth app tests should pass out-of-the-box. Russ > argues no here, a year ago, when closing #7611 wontfix: > > http://code.djangoproject.com/ticket/7611#comment:7 > > saying the auth test failures indicate to the developer that as the project > is currently configured, portions of auth aren't able to work properly. > There's validity in that argument, but here about a month after that we have > committed (by Malcolm): > > http://code.djangoproject.com/changeset/8497 > > a changeset that introduces a new auth test, including a template (and code > to force it to be used) to ensure it passes regardless of what templates the > project provides. I haven't looked into the background for this change too > deeply but on the face of it I don't understand why we'd want to have some > auth tests assuming the project is going to provide templates to make the > tests work and other tests ensuring that they will pass regardless of > whether the project has provided correct templates. > > We've also got this changeset (3 months ago, by Jacob): > > http://code.djangoproject.com/changeset/10482 > > that "fixed the auth tests to ignore broken user-supplied login/logout > templates." That sounds like it directly contradicts the rationale for > closing #7611. > > For unresolved issues, we've got #10976 open (unreviewed) proposing to > include some default templates for auth (for test purposes only, ala the one > added template added in r8497). And #11009 about one of the auth tests no > longer finding the guaranteed-to-work login template added in r8497. And > maybe more...I haven't done a careful search. > > Overall I get the impression we're muddled on the answer to: > > Should the auth tests pass out-of-the-box, independent of other project > configuration? > > Someone making a firm decision on that would help. Personally I'd favor > "yes" as the answer, but I don't feel very strongly about the issue. I'd > accept "no", but if the answer turns out to be "no" I think we should be > consistent on it, and document the requirements for getting "manage.py test" > to pass cleanly in a new project. (And by that I mean list what the > necessary templates are and what characteristics they need -- saying include > 'django.contrib.admin' in INSTALLED_APPS isn't what I mean by documenting > this.)
I don't think the issue here is as simple as saying Yes or No - both are completely valid answers for different use cases. One the one hand, application writers need to be able to test that their application works. You don't care about the templates provided in the project, or the project level settings; app-level testing is entirely self-contained. A freshly downloaded app shouldn't fail any tests (if the release manager is worth their salt). The other side of the coin is integration testing. As a project developer, I integrate your application. I need tests that validate that all the dependencies/requirements of your application are satisfied in my deployment. Project level settings are extremely important here. A freshly downloaded (and integrated) app may well fail multiple tests, depending on the integration requirements of the app. It isn't as simple as saying one case should take priority over the other - both are significant to different audiences. User X, as the author of django-frobnitz, needs app-level testing to ensure when they are preparing the release of v2.3 that the release is bug-free when correctly configured. User Y, a user of django-frobnitz v2.3, can place some trust in the fact that X has tested the release, and really only needs to run integration tests. IMHO, we need to support both. This may mean that some of the following are required: - A way of defining two different test suites - A way of marking an individual test as an 'integration' or 'application' test - A way to execute application tests without the need for a supporting project I've had a few ideas kicking around in the back of my head for a while, but other priorities have stopped those ideas taking any sort of concrete form. Post release of v1.1, this is one of the areas that needs to be thrashed out a bit. It may even be helpful to defer this discussion till DjangoCon, so a bunch of people can stand around a piece of paper and nut out some details. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
