django test-runner annoyances
mvr
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
Carl Meyer
Hash: SHA1
On 09/13/2011 08:46 AM, mvr wrote:
> 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.
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.
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.
But I'm getting off-track -- these should be separate tickets anyway. If
you'd like to file the first one and upload a backwards-compatible
patch, I'm +1 on the concept.
Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk5xC54ACgkQ8W4rlRKtE2eNFgCg7gVEkO6Y+tmXcsWlidmh67ge
SQwAn0PqFg74dy1yLsSPDYab1Jj+jNZ+
=bAbE
-----END PGP SIGNATURE-----
Travis Swicegood
Filip Dupanović
Most of the time, If your app's `tests` module gets too crowded, fracturing the app into smaller apps works. However, if you have to go for the test package approach to maintain sanity, your missing the necessary tools to manage a growing number of test cases; for instance, if you organize your test cases into several modules, there's really no way you can run test cases from a specific module only, without providing a custom test runner or somehow passing arguments to a `suite()` implementation.
mvr
On Sep 14, 4:16 pm, Carl Meyer <c...@oddbird.net> 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.
> 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.
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 <app>" 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.