#17055 closed Bug (fixed)
Fix the errors in the test suite when MySQL is the backend
Reported by: | Jim Dalton | Owned by: | Aymeric Augustin |
---|---|---|---|
Component: | Testing framework | Version: | dev |
Severity: | Release blocker | Keywords: | mysql |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
The work being done in #11665 had fixed all of the errors in the MySQL test run, but it's now broken again due to some recent movement in trunk. Due to other issues with that ticket, I decided it would be better if I split off the goal of fixing the MySQL errors into a separate ticket here.
I'll be attaching a patch that should fix all of the remaining errors in MySQL. The remaining issues are mostly an accumulation of minor errors that have accrued since MySQL does not get properly tested frequently enough. Here's a quick rundown of what the patch fixes:
- There are tests in
regressiontests.multiple_database
that do some funky stuff with the data they load. Basically the load data that couldn't be loaded under normal circumstances. As of #3615 it's possible to disable constraint checks in MySQL to match the default testing behavior of the other backends, so I've done this in the pertinent spots. All tests now pass there.
- This ticket: #16026 improved the error message when loaddata tries to load invalid data. However, MySQL throws a
Warning
instead of raisingIntegrityError
. I trapped the Warning and raise it as an exception and tweaked the test to account for that error type. Tests now pass inmodeltests.fixtures.tests.FixtureLoadingTests
.
regressiontests.admin_scripts.tests.ManageAlternateSettings
was hitting some errors because MySQL uses backticks instead of quotation marks. The tests were assuming backends all used quotation marks. I changed some of the output tests to regex and now they pass.
django.contrib.auth.tests.tokens.TokenGeneratorTest.test_10265
says that a call to create_user and then a get of the same record should return the same password token. Because (at least for my MySQL installation) MySQL does not store microseconds, the second call touser.last_login
(used to create the token) does not have microseconds. The only way to ensure these tokens are always identical is to normalize the last_login datetime so that it's stripped of microseconds. With this fix the test passes.
These are disparate issues however most of them are minor. They are, as it stands, the only issues preventing MySQL from passing all tests. I'm not very well versed in any of them in particular, but if anyone sees a problem with my fixes let me know.
Marking as release blocker to ensure these get fixed before 1.4.
Attachments (1)
Change History (11)
by , 13 years ago
Attachment: | fix_mysql_test_errors.diff added |
---|
comment:1 by , 13 years ago
comment:2 by , 13 years ago
Owner: | changed from | to
---|
Thanks for your work! We definitely need to fix the build on MySQL; there will be a higher incentive to keep it green afterwards. Re-assignig to myself to review the patch.
comment:5 by , 13 years ago
I have committed two easy fixes. The other problems are more complicated:
- we can't import
MySQLdb
inloaddata
: it must be usable by people who don't have MySQL; - the test failures in
multiple_database
don't happen when tests are run in isolation. This is weird —django.test.TestCase
should isolate tests properly. This deserves more investigation.
comment:8 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
As of http://ci.djangoproject.com/job/Django/381/ the build is green.
jsdalton, thank you for your analysis of the failing tests and for the initial patch.
Whoops, just realized I included my fix for #17054 in this patch (reverting a test import in the i18n tests to a * import). That's not relevant to the MySQL test failures (though it was relevant to me because I couldn't run the test suite without it).