Skip to content
This repository was archived by the owner on Nov 30, 2024. It is now read-only.

Conversation

@marcandre
Copy link
Contributor

@marcandre marcandre commented Jun 17, 2020

This PR improves Has's output and makes it consistent with BePredicate:

  1. Fixes the failure message where the result was not true or false. It used to say ", got true/false" no matter what the results are. So it could say "expected ... to return false, got true" when in actuality it's expecting the result to be falsey (upcoming PR) and it got a result of 42!

  2. Failure message for now outputs the receiver.

  3. The description:

...is expected to have taste for "wine", "cheese"

becomes:

is expected to have taste for "wine" and "cheese"

Misc: I also changed a feature example because it was showing a custom matcher has_all_string_keys which, while instructive, could be misinterpreted as an actually useful matcher when the builtin matchers are much better here (e.g. all(be_a String))

This is a prelude to an upcoming PR.

@marcandre marcandre mentioned this pull request Jun 17, 2020
@marcandre marcandre force-pushed the refactor branch 3 times, most recently from fc5c69a to f16bd15 Compare June 17, 2020 22:35
Copy link
Member

@JonRowe JonRowe left a comment

Choose a reason for hiding this comment

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

Can you split this change up into two PRs please, I'd like to assess any refactoring of the matchers without change to their output.

@marcandre marcandre marked this pull request as draft June 18, 2020 13:47
@JonRowe JonRowe changed the base branch from master to main August 2, 2020 02:06
@marcandre marcandre marked this pull request as ready for review August 27, 2020 13:03
@marcandre
Copy link
Contributor Author

@JonRowe rebased, ready for review & merging

Copy link
Member

@benoittgt benoittgt left a comment

Choose a reason for hiding this comment

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

LGTM. Thanks for the side change on feature test. It is much clearer like that.

@JonRowe
Copy link
Member

JonRowe commented Aug 27, 2020

I have concerns about inspecting the target in the message here, if the goal is to be consistent I'd almost rather go the other way and make be not print the inspected targets in the message, e.g. if you have a really big hash (or er, just any ActiveRecord object) then expect(superlong_string).predicate? to return 42 got false is going to be obscured by that string...

@marcandre
Copy link
Contributor Author

if the goal...

The goal is to remove 30 lines of mostly redundant code with a misleading failure message to boot.

I have concerns about inspecting the target in the message here

I don't understand your concern. BaseMatcher#actual_formatted is used in many other matchers, including eq, be_x, ... I'm not sure what logic it has to avoid overly long outputs, but that is orthogonal to this PR.

Please let me what I can do, as I have other yaks waiting...

@marcandre
Copy link
Contributor Author

marcandre commented Aug 29, 2020

@JonRowe What changes (if any) would you like for this to be merged?

@JonRowe JonRowe merged commit d6fee3a into rspec:main Sep 1, 2020
@JonRowe
Copy link
Member

JonRowe commented Sep 1, 2020

I played around with this some and couldn't produce a better output without drastically changing our current behaviour in specs, so merged as is.

JonRowe added a commit that referenced this pull request Sep 1, 2020
@marcandre
Copy link
Contributor Author

Super thanks 🎉

expect {
expect(o).to have_some_stuff
}.to fail_with("expected #has_some_stuff? to return true, got false")
}.to fail_with("expected `#{o.inspect}.has_some_stuff?` to return true, got false")
Copy link
Member

Choose a reason for hiding this comment

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

I'm a bit out of context. Where does the inspect part come from? I would expect the message to be "expected o.has_some_stuff? to return true, got false". Is that something you were referring to in "produce a better output"?

Copy link
Member

Choose a reason for hiding this comment

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

Its because actual e.g o is being printed by the matcher

Copy link
Member

Choose a reason for hiding this comment

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

Got it. I didn't parse it at first.

tgxworld pushed a commit to discourse/discourse that referenced this pull request Jul 28, 2022
* Remove outdated option

rspec/rspec-core@0407831

* Use the non-globally exposed RSpec syntax

rspec/rspec-core#2803

* Use the non-globally exposed RSpec syntax, cont

rspec/rspec-core#2803

* Comply to strict predicate matchers

See:
 - rspec/rspec-expectations#1195
 - rspec/rspec-expectations#1196
 - rspec/rspec-expectations#1277
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants