Unit tests are sensitive to line endings

[SergeyBiryukov]

Currently, patching unit test files with grunt patch on Windows changes line endings.

This results in unexpected failures in some tests using the heredoc syntax (<<<), see #31430.

We should probably set svn:eol-style to native for test files, like we did for core, and do something like str_replace( "\r\n", "\n", ... ) in the tests with heredoc.

[SergeyBiryukov]

31432.patch​ fixes the affected tests.

[wonderboymusic]

Hmmmm, maybe switch to output buffers? I can easily imagine myself forgetting about this being a thing...

[dd32]

The alternative is that we introduce a AssertEqualsIgnoreEOL() style function, or even extend assertEquals to assertEquals($one, $two, $message = '', $allow_mismatched_EOL = true) in our unit test class (which I don't really like).

[boonebgorges]

This is not linked to a specific release, so I'm moving out of the milestone. Please feel free to move back when a decision has been made.

[bobbingwide]

Having detected this line ending problem with Tests_Dependencies_Styles::test_conditional_inline_styles_are_also_conditional, running under Windows on a clone of ​git://develop.git.wordpress.org/ I ran

git config --global core.autocrlf input

checked the file out and the test worked.

...but Tests_Formatting_Autop::test_that_wpautop_skips_line_breaks_after_br then failed.

[SergeyBiryukov]

Related: #46798

[azaozz]

#46798 was marked as a duplicate.

[azaozz]

Seems the "time proven" solution was to use assertContains() when testing HTML output, and avoid the line endings.

Still seeing line endings errors in phpunit/tests/dependencies/scripts.php that are caused by comparing with wp_scripts_print_translations_output that holds some inline JS. It tests translation scripts outputted with printf() in script-loader. Seems we can test it with assertContains() too, perhaps only one line, not the whole script.

[SergeyBiryukov]

This became much more prominent with [46586], seeing 47 failures on trunk.

[SergeyBiryukov]

Replying to dd32:

The alternative is that we introduce a AssertEqualsIgnoreEOL() style function, or even extend assertEquals to assertEquals($one, $two, $message = '', $allow_mismatched_EOL = true) in our unit test class (which I don't really like).

Introducing something like assertEqualsIgnoreEOL() makes sense to me.

We already have assertDiscardWhitespace(), which is not really used anywhere though.

[SergeyBiryukov]

In 46612:

Build/Test Tools: Ignore EOL differences in tests using multiline string assertions.

Unix vs. Windows EOL style mismatches can cause misleading failures in tests using the heredoc syntax (<<<) or multiline strings as the expected result.

Fixes #31432. See #42594, #47411.

[SergeyBiryukov]

In 48443:

Tests: Ignore EOL differences in email tests using multiline string assertions.

Unix vs. Windows EOL style mismatches can cause misleading failures in tests using the heredoc syntax (<<<) or multiline strings as the expected result.

Follow-up to [46612], [48033].

Props davidbaumwald.
See #31432, #41750.

[SergeyBiryukov]

In 48466:

Tests: Ignore EOL differences in some tests using multiline string assertions.

Unix vs. Windows EOL style mismatches can cause misleading failures in tests using the heredoc syntax (<<<) or multiline strings as the expected result.

Follow-up to [46612], [48443].

See #31432.