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

Tracking issue for RFC 1866: More readable assert_eq #41615

Closed
1 of 3 tasks
aturon opened this issue Apr 29, 2017 · 7 comments
Closed
1 of 3 tasks

Tracking issue for RFC 1866: More readable assert_eq #41615

aturon opened this issue Apr 29, 2017 · 7 comments
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@aturon
Copy link
Member

aturon commented Apr 29, 2017

This is a tracking issue for the RFC "More readable assert_eq" (rust-lang/rfcs#1866).

Steps:

Unresolved questions:

  • Should we also cover assert_ne?
  • Should we incorporate color support, or use LLVM-style arrows?
@aturon aturon added B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Apr 29, 2017
@colin-kiegel
Copy link

  • IMO assert_ne should also print multi-lines, but not show a diff
  • Color support in the built-in assert_eq! would be awesome. :-)

small side-note: In case anyone wants to use this before it is stabilized, I just implemented multiline display in pretty_assertions (v0.2) and it currently looks like this:

pretty assertion

@golddranks
Copy link
Contributor

Btw. red and green aren't maybe the best choices for colour coding, as the red-green colour blindness is the most common type of vision deficiency out there. (The coloured pieces would still stand out from the normal text if I understand red-green-colour blindness correctly, but not from each others.)

@colin-kiegel
Copy link

git diff --word-diff does the following by default

The quick brown [-duck-]{+fox+} jumps over the lazy dog

Where [-duck-] and {+fox+} are colored red/green if the terminal supports it. This is also readable without color support (or color blindness). However this might be ambiguous if the underlying text already contains such character sequences.

bors added a commit that referenced this issue Jun 24, 2017
assert_eq failure message easier to read

By having the left and right strings aligned with one another it helps spot the difference between the two far quicker than if they are on the same line.

E.g.
Before:

```
thread 'tests::test_safe_filename' panicked at 'assertion failed: `(left == right)` left:  `"-aandb--S123.html"` right: `"-aandb-S123.html"`',
```

After:

```
thread 'tests::test_safe_filename' panicked at 'assertion failed: `(left == right)`
left:  `"-aandb--S123.html"`
right: `"-aandb-S123.html"`',
```

When the strings are both on the same line it take a lot longer to spot the difference. It is a small change but the small time savings add up with repetition. This would help Rust be an excellent language to write tests in out of the box.

Closes #41615
@ordovicia
Copy link
Contributor

Is this tracking issue supposed to be closed?

@kennytm kennytm reopened this Dec 26, 2017
@kennytm
Copy link
Member

kennytm commented Dec 26, 2017

Thanks @ordovicia.

I've reopened the issue since there are still two unresolved questions (color and arrow).

However AFAIK there can be no "Stabilization PR", the change is insta-stable. For "Adjust documentation", perhaps check the books if the output format needs to be updated, but otherwise no specific documentation is needed for this feature.

@XAMPPRocky XAMPPRocky added the C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. label Jan 22, 2018
@jonas-schievink
Copy link
Contributor

Implement the RFC (#42541)

That does not look like the complete implementation. If it is, then this issue can probably be closed since this has been the stable output since over 2 years now.

@jonas-schievink
Copy link
Contributor

I just re-read the RFC and this is indeed fully implemented. I do not think there's anything left to document/stabilize, and there's also #44838 tracking further improvements to assertion error messages, so closing.

spikespaz pushed a commit to spikespaz/dotwalk-rs that referenced this issue Aug 29, 2024
assert_eq failure message easier to read

By having the left and right strings aligned with one another it helps spot the difference between the two far quicker than if they are on the same line.

E.g.
Before:

```
thread 'tests::test_safe_filename' panicked at 'assertion failed: `(left == right)` left:  `"-aandb--S123.html"` right: `"-aandb-S123.html"`',
```

After:

```
thread 'tests::test_safe_filename' panicked at 'assertion failed: `(left == right)`
left:  `"-aandb--S123.html"`
right: `"-aandb-S123.html"`',
```

When the strings are both on the same line it take a lot longer to spot the difference. It is a small change but the small time savings add up with repetition. This would help Rust be an excellent language to write tests in out of the box.

Closes rust-lang/rust#41615
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

7 participants