Skip to content

Improve equality assertion failure message - #241

Merged
zainab-ali merged 2 commits into
typelevel:mainfrom
zainab-ali:expect-same-failure-message
Nov 11, 2025
Merged

zainab-ali merged 2 commits into
typelevel:mainfrom
zainab-ali:expect-same-failure-message

Conversation

@zainab-ali

@zainab-ali zainab-ali commented Nov 3, 2025 •

Copy link
Copy Markdown
Collaborator

The expect.same and expect.eql methods have expected as their first parameter and obtained as their second.

expected and obtained are printed in the diff report in the failure message, but it's not obvious which parameter is which. To complicate things further, we use found as the parameter name in code, but obtained as the name in the failure message.

This PR improves the failure message to print in expect.same(expected, found). This should help users correlate the diff report to their code.

Before

image

After

image

@zainab-ali
zainab-ali marked this pull request as draft November 4, 2025 10:41
@zainab-ali
zainab-ali force-pushed the expect-same-failure-message branch 5 times, most recently from 8ad0fcb to 3fc5b97 Compare November 4, 2025 14:54
@zainab-ali
zainab-ali marked this pull request as ready for review November 4, 2025 15:12
loc: SourceLocation): Expectations = {
comparisonA.diff(expected, found) match {
case Comparison.Result.Success => Expectations(Validated.validNel(()))
case Comparison.Result.Failure(report) =>

@zainab-ali zainab-ali Nov 4, 2025 •

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One problem with printing - expected and + found is that we assume the Comparison instance will respect the ANSI escape codes and + / - signs in the diff.

I think we can follow this up with some guidance on defining a Comparison.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think the users should have to to worry about it : the comparison report should let untouched by Weaver's selection of colouring in its headers.

If somebody implementing the comparison decides to put some Ansi in their report, Weaver should respect that.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We won't modify their colouring. However if we add the following header text:

val expectedHeader = AnsiColors.c("- expected", AnsiColors.LightRed)
val obtainedHeader = AnsiColors.c("+ found", AnsiColors.LightGreen)

So if a user decides to use - for found, or different colours, the header will be misleading.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. In that case, it's possible that the right course of action is to add this header in the output of the OOTB Comparison Weaver provides

@zainab-ali zainab-ali Nov 7, 2025 •

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could incorporate (+ expected, - found) into the OOTB Comparion, and leave the expect.same / expect.eql text here.

@zainab-ali
zainab-ali force-pushed the expect-same-failure-message branch from 19c816f to 60898c8 Compare November 10, 2025 14:20
@zainab-ali
zainab-ali merged commit 591d4b2 into typelevel:main Nov 11, 2025
13 checks passed
@zainab-ali
zainab-ali deleted the expect-same-failure-message branch November 11, 2025 10:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants