Assert ignoring line ending

[samdark]

In many cases line ending difference doesn't matter at all but the test will fail in many cases because of it. For example:

1. When checked out from git, user may have settings to convert line endings.
2. Line ending differences when running on other OS vs what's used in tests.

We use the following assertion-methods: https://github.com/yiisoft/yii2/blob/master/tests/TestCase.php#L117

That would be great to have line-ending insensitive assertions out of the box.

[samdark]

I can do a pull request if the idea is alright.

[sebastianbergmann]

I could have use this just now for 9504d0d ;-)

[jrfnl]

Hiya!

I've just been looking at the implementation of this and it raises some questions with me regarding the assertStringEqualsStringIgnoringLineEndings implementation:

1. The term Equal (as in assertStringEqualsStringIgnoringLineEndings) is generally used for loose type comparisons in PHPUnit, but is used here for a type safe comparison.
2. The actual comparison done is (mostly) type safe (Same) and would be so even when strict_types would be turned off or if the type declarations in the method would be changed to mixed, due to strtr() being used, which always returns a string.

So, my questions are:

• Is assertStringEqualsStringIgnoringLineEndings() the correct name/assertion to be added ?
  Or should there be an assertEqualsIgnoreLineEndings() and an assertSameIgnoreLineEndings() ?
  This also implies that the normalizeLineEndings() method should allow for receiving mixed type, do a type check and would only normalize if the received type is actually a string (and return the original value unchanged if it isn't).
• And if the new assertions would be transformed like this, what about also recursively handling string values in arrays to allow for a comparison of arrays ignoring line endings ?

I'd be happy to attempt a PR for this, but would like your opinion about this first.

[jrfnl]

Oh and another question: should there be Not versions of these assertions available ?