-
Notifications
You must be signed in to change notification settings - Fork 9
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
error_highlight fix #1339 does not correctly report the issue #140
Comments
This IMO falls into same bucket as rspec/rspec-mocks#1460 and the error message should give even more details what is going on, because this is not transparent, especially at the time a lot of places are already adjusted to account for DidYouMean |
This comment was marked as outdated.
This comment was marked as outdated.
I'm open to improving the error output of this matcher, I don't think its automatically diffed, so it could improve its output when the class matches but the message differs, even leveraging the differ for the error string. Want to have a go at this @voxik? |
Interesting.
It indeed was introduced in rspec/rspec-expectations#1339 . WDYT of changing this to something like? values_match?(@expected_message, actual_error_message.to_s) || values_match?(@expected_message, @actual_error.message) |
I think that this would be good if you preferred backward compatibility and keep the test suite working. However, as I said, this IMO belongs to the same bucket as rspec/rspec-mocks#1460 (it covers new Ruby functionality, but it is not very clear what is going on) and therefore the functionality should stay as it is, the error message should provide more information and all the test suites will need to be adjusted. On top of that RSpec could be extended to be able to test the original output (which is the current situation, but was not the case previously) as well as the output mangled by did_you_mean/error_highlight (if this is deemed interesting, testing the original is probably more valuable). IOW I'd say that the proposed solution could be enough to fix the behavior but the "right breaking" behavior should be introduced at some right milestone. |
IOW it is unfortunate situation that the rspec/rspec-expectations#1339 have been triggered by error_highlight, where the same issues had already happened when did_you_mean was introduced. With did_you_mean, upstreams were forced to update their test suites, while with error_highlight (where the issue with mangled output was probably more prominent), RSpec decided to check the original output, which in turn breaks the test suites which were already adjusted for did_you_mean. |
Trying to execute Thor test suite with rspec-expectations 3.11.0 + Ruby 3.1, I observe the following error:
This brought me to the rspec/rspec-expectations#1339, which is the reason for the error message, but I don't think the reported error is correct. It should actually be:
IOW it should not mention the
Did you mean? "--bar"
, because theoriginal_message
was used for the comparison. I think that this line should be adjusted.This is the test case in question:
https://github.com/rails/thor/blob/ab3b5be455791f4efb79f0efb4f88cc6b59c8ccf/spec/parser/options_spec.rb#L112-L120
The text was updated successfully, but these errors were encountered: