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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
