Re: django test-runner annoyances
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.
Re: django test-runner annoyances
Like Carl and Travis said, Django's test runner supports the notion that a Django app has all it's test cases collected in the `models` and `tests` module. 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. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/76JePQ022ZEJ. 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
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 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.
Re: django test-runner annoyances
-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.
django test-runner annoyances
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.
