On Thu, May 9, 2013 at 5:00 AM, Carl Meyer <[email protected]> wrote: > Hi all, > > 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. > > Great work Carl and Preston! (And everyone else who had a hand in the patch - I know this has been kicking around for a while now)
> 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. > I agree with Jacob's tests aren't production sensitive, so making a fast transition to the new test discovery has less impact. However, we know from experience that it doesn't matter how much we flag this change in the release notes, they won't be read, and *someone* is going to get stung. In an ideal world, it would be good to be able to warn people who upgrade that their test suite may not be run as expected. We've had a proposal kicking around for a while to add a management command that does an "upgrade check". I'm wondering if this might be an opportune time to dig into this some more. To be clear, this isn't something I consider to be a merge blocker. I'd be happy to see 1.6 released with a fast transition to the new test runner. It would just be nice icing on the cake if we can get an upgrade validator included in the same release. Yours, Russ Magee %-) -- 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.
