On Wed, Jun 25, 2008 at 1:17 AM, Marc Fargas <[EMAIL PROTECTED]> wrote:
>
> But oviously, contrib apps should (to not say must) test their views to
> be sure that code released works! Hence, there should be a way for
> contrib apps to have an urls.py and test it.
Agreed. This is something we definitely need to address.
> I can think of two options right now:
> * manage.py test should not run django.contrib.* tests, those are
> supposed to have been run in runtests.py and working fine (that's the
> point of being a contrib app: django developers take care of it!).
> * mange.py test should make sure that django.contrib.*.urls are
> included and disable tests that would fail, or include such urls.
I'm not sure I like either of these options.
There is some value in having end users run tests for django.contrib -
every person that runs the tests is one more person likely to spot
(and report, and maybe fix) a problem. I'm not a big fan of making
special cases, either.
My preferred solution here would be to provide a way for test cases to
substitute a top level URL pattern object for the duration of the
test. For example:
from django.tests import TestCase
class MyTest(TestCase):
fixtures = ['test.json']
urls = 'local.test_urls'
...
The setup methods could swap in a temporary root URLconf, and swap it
out again on teardown. The problem only exists for tests that need to
poke views, so there isn't a huge need for a doctest analog, but the
calls made by TestCase.setup/teardown could be abstracted into
test.utils.
Opinions?
Yours,
Russ Magee %-)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
