Just want to say that I'm happy with a "fast transition". Is there a possibility we can detect the case where the tests might be broken (how might they be?) and print a helpful error message?
Andrew On Thu, May 9, 2013 at 11:51 AM, Russell Keith-Magee < [email protected]> wrote: > > 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. > > > -- 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.
