Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allow configuration of character count in string diff formatting #346

Closed
mitchdraft opened this issue Apr 29, 2019 · 4 comments
Closed

allow configuration of character count in string diff formatting #346

mitchdraft opened this issue Apr 29, 2019 · 4 comments

Comments

@mitchdraft
Copy link
Contributor

from format/format.go:

/*

Generates a nicely formatted matcher success / failure message

Much like Message(...), but it attempts to pretty print diffs in strings

Expected
    <string>: "...aaaaabaaaaa..."
to equal               |
    <string>: "...aaaaazaaaaa..."

*/

func MessageWithDiff(actual, message, expected string) string {

and https://github.com/onsi/gomega/blob/master/format/format.go#L146

we get 5 characters of context around the first diff in a string comparison assertion error message.

5 characters is often enough, however when comparing large structs, as can be the case with protobuf messages example it would be useful to have more context. Otherwise, long values can obscure the key, and make it harder to back-out the issue.

Suggestion: export format.CharactersAroundMismatchToInclude

@williammartin
Copy link
Sponsor Collaborator

Thanks for the issue. Just to check, the format.TruncatedDiff value set to false isn't satisfactory for you here?

@mitchdraft
Copy link
Contributor Author

Thanks for pointing that out, I hadn't considered it.
Still, I find the truncation super helpful on large structs. It has offered a nice balance of ease-of-test creation and usefulness of error messages.

In this util, for example. here are my notes on the alternatives - feedback welcome, maybe there's a better way

@mitchdraft
Copy link
Contributor Author

additional note - we also decided to avoid MatchFields so as to avoid overlooking any new fields that might be added in the future

@blgm
Copy link
Collaborator

blgm commented Feb 12, 2021

This was resolved by #347

@blgm blgm closed this as completed Feb 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants