#18920 closed Bug (fixed)
Regresssiontests.template tests fail on windows due to expected '\n'
Reported by: | Michael Manfre | Owned by: | nobody |
---|---|---|---|
Component: | Testing framework | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | yes |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | yes | UI/UX: | no |
Description
====================================================================== FAIL: test_inclusion_tags (regressiontests.templates.custom.CustomTagTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\projects\django\tests\regressiontests\templates\custom.py", line 112, in test_inclusion_tags self.assertEqual(t.render(c), 'inclusion_no_params - Expected result\n') AssertionError: u'inclusion_no_params - Expected result\r\n' != u'inclusion_no_params - Expected result\n' ====================================================================== FAIL: test_inclusion_tags_from_template (regressiontests.templates.custom.CustomTagTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\projects\django\tests\regressiontests\templates\custom.py", line 194, in test_inclusion_tags_from_template self.assertEqual(t.render(c), 'inclusion_no_params_from_template - Expected result\n') AssertionError: u'inclusion_no_params_from_template - Expected result\r\n' != u'inclusion_no_params_from_template - Expected result\n' ====================================================================== FAIL: test_post_callbacks (regressiontests.templates.response.SimpleTemplateResponseTest) Rendering a template response triggers the post-render callbacks ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\projects\django\tests\regressiontests\templates\response.py", line 145, in test_post_callbacks self.assertEqual(response.content, b'First template\n') AssertionError: 'First template\r\n' != 'First template\n' ====================================================================== FAIL: test_template_resolving (regressiontests.templates.response.SimpleTemplateResponseTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\projects\django\tests\regressiontests\templates\response.py", line 34, in test_template_resolving self.assertEqual(response.content, b'First template\n') AssertionError: 'First template\r\n' != 'First template\n'
Attachments (1)
Change History (16)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
Patch needs improvement: | set |
---|---|
Triage Stage: | Unreviewed → Accepted |
On Python 3, you cannot concatenate bytes and str, so you will need to encode linesep (last three in your patch).
comment:3 by , 12 years ago
Patch needs improvement: | unset |
---|
Updated pull and now using force_bytes for the last three. I don't have a Python 3 environment to test it out right now.
comment:4 by , 12 years ago
#18926 was a duplicate, but it suggests another way of solving this (at git level with .gitattributes).
comment:5 by , 12 years ago
I do run the test suite on Windows, and have not run into this issue. Apparently when I installed git on Windows (git --version reports for me git version 1.7.10.msysgit.1
), it either defaulted to setting core.autocrlf
to input
or I told it to do so. Ultimately I think that is the right approach: tell git to NOT alter line endings. If the .gitattributes file can help with that, we should add that as well. I don't think we should change the tests to account for different line endings on Windows/Linux/Mac (does Mac still have yet a different convention or have they changed to LF only?) because that is fragile: people will add new tests without remembering to account for line ending differences across platforms and those tests will break on non-Linux platforms. Instead we should document that if you are using git on Windows you should configure git to have core.autocrlf
set to input
and/or include a .gitattbutes file that prevents the "wrong" setting for this value from causing problems.
comment:6 by , 12 years ago
What about tests run not from git checkout but with a downloaded tarball?
comment:7 by , 12 years ago
Those don't have any problem...the problem is introduced by git configurations which change LF in the files in the repo to CRLF on Windows.
comment:8 by , 12 years ago
Which, now that you mention it, is another reason to not change the tests. If we change the tests to expect CRLF line endings when running on Windows then people who download the tarball to Windows and run tests from that install will see errors, because going that route doesn't auto-convert line endings to CRLF.
comment:9 by , 12 years ago
Adding a .gitattributes file to the repository, as suggested in #18926, would seem like the best approach, as this is clearly an issue with git/github, not the code or tests.
comment:10 by , 12 years ago
Needs documentation: | set |
---|
I figured that if #18926 is a duplicate, then the suggested .gitattributes file that dlanger added and tested there seems like a possible solution here. I will test the solution on Windows shortly. If we do add the .gitattributes file, I think it is necessary to document the change somewhere and possibly adding a note about Windows Git and line endings to the installation docs.
Does anyone think that it would be very intrusive to force LF line endings on all html files in Django? Seems to be a reasonable way to ensure a consistent user testing experience with regards to line endings.
comment:11 by , 12 years ago
Tested and confirmed that adding .gitattributes file to repo before clone fixes aforementioned unit tests. Used Windows Git-1.8.0-preview20121022 and Django master.
comment:12 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Pull request.
https://github.com/django/django/pull/330