Not good, at least our Jenkins runner which should generate xml output 
doesn't like it :/

On Saturday, May 11, 2013 5:36:55 AM UTC+2, Carl Meyer wrote:
>
> 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.


Reply via email to