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.
