I merged this patch tonight. Thanks to everyone who contributed! Now let's see how the CI servers feel about it...
Carl On Wednesday, May 8, 2013 5:00:56 PM UTC-4, Carl Meyer wrote: > > Preston Timmons and I have been working the last several weeks to get > the test discovery branch (#17365) ready for merge, and I think we now > have a pull request ready for consideration: > https://github.com/django/django/pull/1050 > > Brief summary of the features, changes, and open questions: > > * You can now place tests in any file matching the pattern 'test*.py', > anywhere in your codebase, rather than only in tests.py and models.py > modules of an INSTALLED_APP. The filename pattern is customizable via > the --pattern argument to "manage.py test". > > * When you run "manage.py test" with no arguments, tests are discovered > and run in all subdirectories (recursively) of the current working > directory. (This means that django.contrib and other third-party app > tests are no longer run by default). > > * When you pass arguments to "manage.py test", they are now full Python > dotted module paths. So if you have a "myproject.myapp" app, and its > tests.py contains "SomeTestCase", you would now run that single test > case via "manage.py myproject.myapp.tests.SomeTestCase" rather than > "manage.py myapp.SomeTestCase". This is longer, but allows more control > when an app's tests are split into multiple files, and allows for tests > to be placed anywhere you like. > > * Doctests are no longer discovered by default; you will need to > explicitly integrate them with your test suite as recommended in the > Python docs: http://docs.python.org/2/library/doctest.html#unittest-api > > * Tests in models.py and tests/__init__.py will no longer be discovered > (as those don't match the default filename pattern). > > * The old test runner, and Django's extensions to the doctest module, > are deprecated and will be removed in Django 1.8; they could of course > be packaged separately if some people would like to continue using them. > > Open question: how to handle the transition? > > Jacob has suggested that back-compat breaks in test-running are not as > serious as in production code, and that we should just switch to the new > test runner by default in Django 1.6. This is what the pull request > currently does. This will mean that some people's test suites will > likely be broken when they upgrade to 1.6. They would have two options, > both documented in the release notes: they can update their test suite > to be discovery-compatible immediately, or they can just set TEST_RUNNER > to point to the old runner and get back the old behavior, which they can > keep using until Django 1.8 (or longer, if they package the old runner > externally). > > The alternative would be to keep the old test runner as the default in > global_settings.py until it is removed in 1.8, and add the new runner as > the TEST_RUNNER in the startproject-generated settings.py. This would > provide a gentler transition for upgrading projects. On the other hand, > we just recently got the startproject settings.py all cleaned-up, > slimmed-down, and newbie-friendly, so it would make me sad to start > polluting it again with stuff that new projects generally shouldn't care > about, for solely legacy reasons. > > Thoughts, questions, comments, code review and testing welcome! I'd like > to merge this on Friday (it's a bear to keep updated with trunk), so let > me know if you need longer. > > Carl > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
