tests: improve captureTestingT helper

[ccoVeille]

Summary

A simple change to provide more explicit errors message when testing the code while refactoring asserters

Changes

This helper is used to capture the testing.TB interface, and compare
the log output with the expected output.

This is useful for testing and refactoring purposes.

This commit improves the helper by displaying:

• the captured and expected outputs on a newline.
• the special characters in the captured output, such as newlines and tabs.

Both help with readability.

Here is an example of the output before and after the change:

Before:

    assertions_test.go:3422: Logged Error: Should be in error chain
        expected: *assert.customError
        in chain: "EOF" (*errors.errorString)
    assertions_test.go:3422: Should log Error: Should be in error chain:
        expected: *assert.customError
        in chain: "EOF" (*errors.errorString)

After:

My initial implementation:

assertions_test.go:3486: Logged Error:
        Should be in error chain\n
        expected: *assert.customError\n
        in chain: "EOF" (*errors.errorString)\n
    assertions_test.go:3486: Should log Error: Error:
        Should be in error chain:\n
        expected: *assert.customError\n
        in chain: "EOF" (*errors.errorString)

The final implementation after applying @dolmen suggestion:

     assertions_test.go:3394: Recorded Error: "Should be in error chain:\nexpected: *assert.customError\nin chain: \"EOF\" (*errors.errorString)\n"                                         
     assertions_test.go:3394: Expected Error: "Should be in error chain\nexpected: *assert.customError\nin chain: \"EOF\" (*errors.errorString)"

The new format helps to identify the differences:

• the missing colon after "Should be in error chain"
• the extra newline in the captured output

Motivation

I spent 10 minutes on this change, because I lost 10 minutes in
finding the differences between the captured and expected output on a
refactoring I was doing.

Related issues

Replaces: #1735 opened with the wrong fork

[dolmen]

Why not just log the error using %q?

[ccoVeille]

Why not just log the error using %q?

I had no idea %q was escaping the \n or \t character

[ccoVeille]

I can change, but then if becomes a matter of style

but I feel like this is more readable

        assertions_test.go:3422: Logged Error: Should be in error chain                                                                                                                        
            expected: *assert.customError                                                                                                                                                      
            in chain: "EOF" (*errors.errorString)                                                                                                                                              
        assertions_test.go:3422: Should log Error: Should be in error chain:                                                                                                                   
            expected: *assert.customError                                                                                                                                                      
            in chain: "EOF" (*errors.errorString)                                                                                                                                              

than:

        assertions_test.go:3394: Recorded Error: "Should be in error chain:\nexpected: *assert.customError\nin chain: \"EOF\" (*errors.errorString)\n"                                         
        assertions_test.go:3394: Expected Error: "Should be in error chain\nexpected: *assert.customError\nin chain: \"EOF\" (*errors.errorString)"

I can apply the change you request @dolmen, it matches my needs, but I'm not fan of the rendering.
The main issue is with the way the quote are escaped.

EDIT: I decided to live with it, it only happens when dealing with quote, and when an error message is updated.

[ccoVeille]

Why not just log the error using %q?

done

[ccoVeille]

@dolmen

I feel like I could use back tick with CanQuote as you did in a previous PR

What do you think?