It would be really nice to be able to use same syntax for running a single Django's testcase at least for a while. I expect that there will be problems if inspecting how a given test case behaves in older versions compared to HEAD. Also, bisecting over the test case renaming boundary will be really ugly. I don't believe end users will have too much problems with this, but bug hunting and development in Django itself will be a bit more tedious to do.
I don't have any bright ideas of how to do this nicely. Maybe just try the new way, if no tests found, then try to convert appname.SomeClass to projectname.appname.tests.SomeClass, and somehow do this only for tests/runtests.py. Otherwise the plan looks good to me. And the above issue isn't anything severe, just something that would make developing Django a bit easier in certain cases. - Anssi On 9 touko, 00:00, 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. > > 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.
