Just to clarify -- the failure I hit in the Django test suite after
re-ordering rolled back test cases to run first is not one where a test
assumes another runs before it (rather the reverse) or one that can be
triggered currently by just running that single test in isolation. If you
run just file_uploads on today's trunk, you'll see:
python runtests.py --settings=sqlite --verbosity=2 file_uploads
[snipped a bunch of output]
No fixtures found.
The correct IOError is raised when the upload directory name exists but
isn't a directory ... ok
Permission errors are not swallowed ... ok
test_broken_custom_upload_handler
(regressiontests.file_uploads.tests.FileUploadTests) ... ok
test_custom_upload_handler
(regressiontests.file_uploads.tests.FileUploadTests) ... ok
Uploaded file names should be sanitized before ever reaching the view. ...
ok
test_file_error_blocking
(regressiontests.file_uploads.tests.FileUploadTests) ... ok
File names over 256 characters (dangerous on some platforms) get fixed up.
... ok
test_fileupload_getlist (regressiontests.file_uploads.tests.FileUploadTests)
... ok
test_large_upload (regressiontests.file_uploads.tests.FileUploadTests) ...
ok
test_simple_upload (regressiontests.file_uploads.tests.FileUploadTests) ...
ok
----------------------------------------------------------------------
Ran 10 tests in 3.392s
OK
Destroying test database...
If you run it, unchanged, with rolled back transactions that are re-ordered
to be run first, you see:
python runtests.py --settings=sqlite --verbosity=2 file_uploads
[snipped a bunch of output]
test_broken_custom_upload_handler
(regressiontests.file_uploads.tests.FileUploadTests) ... ok
test_custom_upload_handler
(regressiontests.file_uploads.tests.FileUploadTests) ... ok
Uploaded file names should be sanitized before ever reaching the view. ...
ok
test_file_error_blocking
(regressiontests.file_uploads.tests.FileUploadTests) ... ok
File names over 256 characters (dangerous on some platforms) get fixed up.
... ok
test_fileupload_getlist (regressiontests.file_uploads.tests.FileUploadTests)
... ok
test_large_upload (regressiontests.file_uploads.tests.FileUploadTests) ...
ok
test_simple_upload (regressiontests.file_uploads.tests.FileUploadTests) ...
ok
The correct IOError is raised when the upload directory name exists but
isn't a directory ... ERROR
Permission errors are not swallowed ... ok
======================================================================
ERROR: The correct IOError is raised when the upload directory name exists
but isn't a directory
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/home/kmt/tmp/django/trunk/tests/regressiontests/file_uploads/tests.py",
line 259, in test_not_a_directory
fd = open(UPLOAD_TO, 'w')
IOError: [Errno 21] Is a directory: '/tmp/tmpud5FFp/test_upload'
----------------------------------------------------------------------
Ran 10 tests in 1.949s
FAILED (errors=1)
The problem is tests/regressiontests/file_uploads/test.py contains both a
unittest.TestCase (named DirectoryCreationTests) and a django.test.TestCase
(named FileUploadTests). Given their names (Directory... sorts before
File...), they are run in that order on today's trunk, and in that order
they both pass. If you switch their order (only the FileUploadTests becomes
a rolled-back testcase that gets moved to the front of the suite) you get
the "The correct IOError is raised when the upload directory name exists but
isn't a directory" failure because the FileUploadTests has a (not cleaned
up) side-effect of creating a directory where the unittest.TestCase assumes
it can create a file.
I tend to agree that this is a flaw in this test set, and it is easily
fixed, but it is not a failure you can see today by just running a test in
isolation. You'd have to do something like change the test names so that
the FileUploadTests sorted lexically (and thus ran before) the other test.
All that said, I, personally, would prefer to make the new rolled-back test
case replace the existing django.test.TestCase and require people to opt-out
(switch to TransactionTestCase) if they want/need the old behavior. The
rollback approach does provide a significant performance boost and it would
be nice if people could just take advantage of it by default with 1.1. I do
fear it may be overlooked by some if code changes are required to use it.
But I did want to point out that the effects of the re-ordering done to put
the rolled-back transaction test cases first may be a little more subtle
than expected, in case that sways anyone's opinion towards requiring opt-in
for getting the new behavior.
Karen
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
