Make simpletest assertions output both the default and custom message texts

So this a lot more than I thought it would be, but I couldn't think of another way to make it backportable.

I have not proofread this patch and I do not guarantee that it is not typo-ridden, incorrect, buggy, inconsistent, or on fire.

Help me testbot! You're my only hope.

NORLY

+++ b/core/modules/simpletest/lib/Drupal/simpletest/WebTestBase.phpundefined
@@ -2325,9 +2353,10 @@ abstract class WebTestBase extends TestBase {
+      'Pattern "@pattern" not found', array('@pattern' => $pattern),

Missing format_string() here. That should fail prettily.

+++ b/core/modules/simpletest/lib/Drupal/simpletest/WebTestBase.phpundefined
@@ -2498,19 +2529,18 @@ abstract class WebTestBase extends TestBase {
+      $default_message = t('Found field with name @name', array(
...
+      $default_message = t('Found field with name @name and value @value', array(

@@ -2580,7 +2625,11 @@ abstract class WebTestBase extends TestBase {
+      t('Checkbox field @id is checked.', array('@id' => $id)),

Missed a t() here, at least.

With issues in #3 fixed. Still haven't proofread thoroughly.

(Edited.)

So, this is interesting.

1. SimpleTest inserts the assertion messages into a database table when it runs. The first fail above is on:

   $this->assertEqual($out, $expected, 'CJK tokenizer worked on all supplied CJK characters');
   

   where $out and $expected have (as one might infer) a bunch of CJK unicode. In current core, that data is eliminated from the message, but with the patch, the DB chokes on this:
   PDOException: SQLSTATE[HY000]: General error: 1366 Incorrect string value: '\xF0\xA0\x80\x80 \xF0...' for column 'message' at row 1: INSERT INTO {simpletest} (test_id, test_class, status, message, message_group, function, line, file) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7); Array ( [:db_insert_placeholder_0] => 7 [:db_insert_placeholder_1] => SearchTokenizerTestCase [:db_insert_placeholder_2] => pass [:db_insert_placeholder_3] => Value '一 盨 鿏 㐀 䃠 䶿 豈 切 﫿 ᄀ ᆀ ᇿ ꥠ ꥰ ꥿ ힰ ퟘ ퟿ ㄱ ㅠ ㆎ ａ ｎ ｚ ａ ｎ ｚ ｦ ﾡ ￜ 가 쇘 힯 ぀ ば ゟ ァ バ ヿ ㇰ ㇸ ㇿ

2. The failing database tests connection appear to be due to the fact that var_export() blows up (recursing somehow?) when used on a database connection.
3. The CSS unit tests and line break filter test give a weird message that seems to imply the DB table is missing; I haven't debugged that further.
4. The image field display tests, image style tests, and OpenID tests all appear to be throwing the same "invalid multibyte sequence" warnings when binary data is used as a test value in the assertion.
5. The aggregator feed assertion warning is coming from:
   

   $this->assertResponse(array(200), t('URL !url is accessible', array('!url' => $edit['url']))); 
   

6. The XMLRPC tests are failing because the message is too long to insert.

#1 and #7 could potentially be fixed in the assertionMessage() method, but the others are happening upstream in the assertions when trying to generate the default messages from the passed data. This would be easier to fix if assertions were objects.

So this should eliminate some but not all of the failures.

Hmm. So #3 and #4 ran on 803 and got failures I can reproduce locally, but #7 ran on 654 and had different failures, including update path test stuff again. Retesting that.

Edit: So the "invalid multibyte sequence in argument" errors appear to happen on 803 but not 654.

Failure #6 in my list is actually a bug in assertResponse():

  protected function assertResponse($code, $message = '') {
    $curl_code = curl_getinfo($this->curlHandle, CURLINFO_HTTP_CODE);
    $match = is_array($code) ? in_array($curl_code, $code) : $curl_code == $code;
    $message = $this->assertionMessage(
      format_string(
	'HTTP response expected !code, actual !curl_code',
        array('!code' => $code, '!curl_code' => $curl_code)
      ),
      $message
    );
    return $this->assertTrue($match, $message, t('Browser'));
  }

The assertion accepts either an array or a string, but when passed an array, it tries to just print the array as a string argument.

The attached fixes #10 and also addresses the resource ID issue.

+++ b/core/includes/common.incundefined
@@ -5097,6 +5097,28 @@ function drupal_valid_token($token, $value = '', $skip_anonymous = FALSE) {
 
+
+/**

Extra blank line there.

Not sure where the interdiff went, but here it is.

See also #1601146: Allow custom assertion messages using predefined placeholders.

With workarounds for the handful of assertions in core that are not compatible with var_export() because of circular references, plus the CJK thing which I couldn't figure out how to solve. Unfortunately I think the options are to either add a more sophisticated variable exporter, or not to backport this.

Screenshot showing what some test results look like with this patch: