In WebTest code, assertEqual and assertIdentical should always show the 2 values on failure

@pwolanin, interesting thought. But both the methods return messages on both pass or fail. As an example if I test with TestBase::assertEqual('foo', 'bar') and should it not give me Value 'foo' is equal to value 'bar'? From that message we can surely identify that the test failed. But yes, we can have something like $this->verbose() if the assertion fails.

What are your thoughts on this?

Thanks.

So this overwrites the existing message which on failure seems fine. Should we concatenate both?

I don't see any reason not to do this, let's do it for assertEqual as well?

Got you @pwolanin, I'll also have a go..

Uploading a new patch. Please review!

Maybe let's concatenate it with the original message, just in case people do a search for it in the results still expecting the old behavior.

Can we have screenshots of what this looks like in CLI and web interface just to make sure the separator looks good?

Patch looks great, this seems super useful!

+++ b/core/modules/simpletest/src/TestBase.php
@@ -689,7 +694,17 @@ protected function assertEqual($first, $second, $message = '', $group = 'Other')
+    // Cast objects implementing SafeStringInterface to string instead of
+    // relying on PHP casting them to string depending on what they are being
+    // comparing with.
+    $first = $this->castSafeStrings($first);
+    $second = $this->castSafeStrings($second);

Seems we missed that one in #2560729: Cast objects implementing SafeStringInterface to string in TestBase / WebTestBase. I think we can include this in this patch because the added var_export may otherwise fatal on a test fail.

@pwolanin & @stefan.r, shouldn't we use PHP_EOL newline character in a cross-platform-compatible way, so it handles DOS/Mac/Unix issues?
Uploading a patch with PHP_EOL and marking for review.

Also a thought, the CLI output gives a new line break with the message & the default message. But the WebUI doesn't. Should it be good if for WebUI this new line break is converted to HTML break line?

What do you guys think about this?

@pwolanin, I do agree with your thoughts. Using "\n" doesn't create any problems with Drupal in Unix or Mac OS, but might create issues in Windows because,

• Unix / Linux / OS X uses LF (line feed, '\n', 0x0A)
• Macs prior to OS X use CR (carriage return, '\r', 0x0D)
• Windows / DOS uses CR+LF (carriage return followed by line feed, '\r\n', 0x0D0A).

Source:https://en.wikipedia.org/wiki/Newline

And also current core uses a lot of "\n" and lesser PHP_EOL. Yes, this is totally out of scope to convert newline to line break. A basic algorithm could be,

1. Detect PHP_SAPI
2. Set variable based on PHP_SAPI return: Either PHP_EOL (PHP_SAPI = true) or <br />(PHP_SAPI = false)

However, the questions are,

1. Should we allow PHP_EOL in this fix? - Great if others provide their feedback as well.
2. Should we create a new task that replaces "\n" where necessary with PHP_EOL or <br />?

Thanks!

Committed f5647da and pushed to 8.0.x. Thanks!