On Oct 6, 1:25 pm, Russell Keith-Magee <freakboy3...@gmail.com> wrote:
> I think we need something else. In particular, I think we need to
> address the problem at a slightly deeper level - we need to
> acknowledge that we don't differentiate between application tests and
> integration tests within Django's test framework.
That's a really interesting idea - I've been thinking about it over
the past couple of days and it does seem to make sense. I'm having
trouble imagining exactly how it would work, but I can see that tests
which identify problems with the user's configuration are useful, but
should absolutely be kept separate from those tests that verify that
the application works as a standalone chunk of code.
Are we talking about something like this?
./manage.py test # run application tests
./manage.py test --integration # run integration tests
> 1. Reverse the decision of #7611, and make the current contrib.auth
> test suite a genuine collection of app tests.
>
> 2. Add extra tests to validate the integration case. These tests
> would be conditional, depending on exactly what has been deployed. For
> example: one test would look to see if
> contrib.auth.views.password_change has been deployed in the project.
> If it has, then the test would try to GET the page. The test passes if
> the page renders without throwing a missing template warning. However,
> if the view isn't deployed, the test is either not run, or is passed
> as a no-op. Essentially, the integration tests should be trying to
> catch every way that you could misconfigure your deployment of an
> application in a project.
Conditional tests sound a little bit brittle to me - I think I prefer
the model where a user explicitly requests the integration tests to be
run.
> Making this happen will require two pieces of infrastructure:
>
> * Firstly, we need a way to make app tests completely independent of
> the project environment. We started down this path when we added
> TestCase.urls, and the patch on #7611 adds another little piece of the
> puzzle. What we really need is a way to address this consistently for
> _all_ application settings - including those provided by the
> application itself. However, it isn't as simple as creating a new
> settings object, because some settings - such as database settings -
> need to be inherited from the test environment.
This is really interesting, because it fits in with my personal
vendetta against settings.py as a whole - the single reason I dislike
settings.py is that I often find myself wanting to use different
settings for different parts of the same application. Running tests
feels like an extension of that desire (and is in many ways a more
obvious use case).
> * Secondly, we need to make sure that we can easily establish if
> integration conditions need to be tested. reverse() already does much
> of the job here, but some helpers to make it easy wouldn't go astray.
As someone who likes to experiment with alternative ways of
constructing an application (see djng) I'm still not a big fan of
reverse, which tightly couples me to defining all of my URLs in
urls.py with references to real solid functions (rather than re-
dispatching through whatever crazy mechanism takes my fancy on that
particular day). Again, it might turn out that there's a nicer
alternative to integration tests that attempt to run conditionally on
configuration. I'm very unclear on how any of this would work though.
It sounds to me like splitting tests in to application v.s.
integration tests is going to be a lot of work - work that's worth
doing, but it's not going to be a quick fix. I'd like to find a quick
temporary fix for the auth-tests-fail-by-default problem that can at
least resolve this particular issue rather than holding out for a
large scale refactoring of the test framework. Shipping default
registration tests with the contrib.auth app feels like the easiest
option here, especially since default templates would be a useful
feature of that part of the framework anyway.
If we were to ship default templates, simply using {% extends base %}
and providing an argument to the generic views that allows the user to
specify their own base template would be enough to ensure easy
integration with a custom design (and hence work around what I assume
is the reason we didn't ship default templates in the first place).
Does that sound reasonable?
Simon
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
