run-tests.sh script truncates test results output, making debugging sometimes difficult

[elisseck]

Description of the need

In /core/scripts/run-tests.sh L#948 the testing script is truncating output from test results. I think someone probably did this so the column data width would somewhat match the column header width. I think matching widths is not as important as getting all the debugging output when working on tests:

  $summary = sprintf(
    "%-9.9s %-10.10s %-17.17s %-7.7s %-72.72s\n",
    $results_map[$result->status],
    $result->message_group,
    basename($result->file),
    $result->line,
    $function
  );

This can lead to frustrating results output, especially in the contrib space where filenames can be long, or when debugging test failures or exceptions that only happen through github actions. My workaround so far has been to fork backdrop and run contrib tests against a patched version of core to see results in GHA.

Here is an example of truncated results:

Notice entity_token.toke or commerce_product_ as truncated filename results. The latter could match several files one would need to hunt through to find out where this sort of issue could potentially be happening.

Proposed solution

Do not truncate the results output from simpletest. It's more important to see full results than to have columns line up.

Alternatives that have been considered

We could potentially just increase the length, but I think inevitably someone else will run into this again if they have really long filenames in a module with tests.

[quicksketch]

For comparison, I ran some failing tests before and after the PR.

Before:

After:

Note that these messages only show up at all if there are failures, so you can't see the demonstrated output on the PR where all tests are already passing.

I do appreciate the padding provided by sprintf() to align the columns, generally.

I would expect that there must be a way to pad the strings in way where we pad a minimum number of spaces, but if the filename or function name is longer, we let it overflow. I'm not super-familiar with sprintf but I'll experiment.

[herbdool]

@elisseck would you like to try implement the change Nate is suggesting?

[elisseck]

@herbdool sure, I will try to take on the experimenting noted above instead.