Hello; I second all of what Carl said and would like to point out the app-refactor. I believe the most current code still lives in the app-loading branch on jezdez's repository on GitHub[1]. The reason I point this out is because the current testing structure is a legacy of the way Django internally finds out what "apps" are tested. I've gone down this rabbit hole before and the solution I ended up with was modifying the way loading apps worked which has all manner of side-effects. One of the first steps down that path is the app-loading branch which makes referring to an app by it's full name possible.
-T [1]: https://github.com/jezdez/django/tree/app-loading On Wed, Sep 14, 2011 at 3:16 PM, Carl Meyer <c...@oddbird.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > 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----- -- 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.
