django test-runner annoyances

[mvr]

Why doesn't the django test management command / test builder allow
fully-qualified package names instead of just app-relative ones?

At work we've been using the method below to monkey-patch the test
builder, so that

 $ django-admin.py test my_module.my_app.tests.some_test_file

always works as expected.  We'd like to get rid of this monkey-patch,
and since this functionality can be added in such a way that it's
completely backwards compatible, where is the harm?  I'm also willing
to submit a diff that modifies django in-place, but the monkey patch
below should be easy to read and first I wanted to hear if anyone has
any thoughts on why the existing behaviour really is exactly what it
should be.



def _support_dotpaths():
""" allows real dotpaths to be used as test labels for
django's test runner
first we maintain the status quo by doing whatever django
does, then
just do it the way that they should have done it in the
first place.
"""
import unittest
from django.db.models.loading import ImproperlyConfigured
from django.test import simple
django_build_test_test = simple.build_test
def my_build_test(label):
fallback = lambda:
unittest.TestLoader().loadTestsFromName(label)
try:
return django_build_test_test(label)
except ValueError, v:
if 'should be of the form' in str(v):
return fallback()
else:
raise
except ImproperlyConfigured,e:
if 'App with label' in str(e):
return fallback()
else:
raise
simple.build_test = my_build_test
return my_build_test

-- 
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.

Re: django test-runner annoyances

[mvr]

On Sep 14, 4:16 pm, Carl Meyer  wrote:
>
> I'm generally in favor of updating Django's test runner to be more
> consistent with what the rest of the Python testing world does. Being
> able to reference test files, suites, and tests by
> fully-qualified-dotted-path rather than magical-applabel-path would be a
> good start, IMO.

I'll cut a ticket and submit a patch.

> Another piece would be adding support for unittest2 test discovery, to
> lift the requirement that all tests have to live directly in tests.py or
> models.py. It's not that I think putting tests inside a tests package is
> a bad convention, but if you have a lot of tests it's unfortunate that
> you currently have to manually import all the suites into tests/__init__.py.

We kind of have a fix for this too, and although it is not in the test-
runner itself or the management command it easily could be.

It involves adding one line to tests/__init__.py and never touching it
again.. that line looks like this:

__all__ = import_test_classes(__file__, __name__)

The implementation, which leverages unittest2 test loading magic, is
detailed here: http://dpaste.com/615679/

(Not sure whether dpaste or code in messages is worse form, but the
formatting on my first email looked bad..)

Regarding Swicegood's remarks about app-refactor, Yes, the first part
of what motivates full dotpaths for us is duplicate app names.  Second
is stuff like being able to run tests locally that the build process
won't discover (ie things defined in tests/some_file.py but not
imported in tests/__init__.py).  Third is running a very specific test
to save time iterating during TDD.

I also have a stand-alone workaround (as in, works with django 1.3 out
of the box) so that "dad test " still loads all tests even with
duplicate app names.  I didn't intend to open that can of worms here
since I'm not sure it's of interest with the app refactor up-and-
coming.  If anyone IS interested let me know.. it does require
modifying the test runner itself and not just patching some little
helper.

-- 
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.