Follow frozen_string_literal and equal and be matchers behavior in docs
#1303
Conversation
| @@ -582,7 +582,7 @@ def eql(expected) | |||
| # | |||
| # @example | |||
| # expect(5).to equal(5) # Integers are equal | |||
| # expect("5").not_to equal("5") # Strings that look the same are not the same object | |||
There was a problem hiding this comment.
I believe there is no point to compare two string literals, so this comment describes the case when some non-literal actual value is compared with equal with an expected literal might result in a failure.
BTW, the use of equal instead of be_equal seems to be the real problem here.
There was a problem hiding this comment.
Sure.
| # expect("5").not_to equal("5") # Strings that look the same are not the same object | |
| # expect(+"5").not_to equal(+"5") # Strings that look the same are not the same object |
So this is a way (or use dup). Is it better?
There was a problem hiding this comment.
What are you after with this change in the first place?
There was a problem hiding this comment.
#1303 (comment) is the my motivation
There was a problem hiding this comment.
To me, the current doc says "don't use equals unless you absolutely know what you're doing, e.g. if you compare identical strings that are not the same object, the comparison would fail".
Do you think adding + would help to make this more clear for developers of all experience levels?
There was a problem hiding this comment.
Ah thanks, that is the documentation direction of this project, I understood.
| @@ -92,6 +92,8 @@ Feature: Equality matchers | |||
| Scenario: compare using equal (equal?) | |||
| Given a file named "compare_using_equal.rb" with: | |||
| """ruby | |||
| # frozen_string_literal: false | |||
There was a problem hiding this comment.
As far as I know, # frozen_string_literal: false makes the old ruby behaviors for string literals.
Recent projects basically prefers # frozen_string_literal: true. Then ruby handles same string literal as a same object.
So clarifying to set false does not make confusion when reading docs as a tutorial. I think.
There was a problem hiding this comment.
We use .feature files for two purposes:
-
Documentation, that is published to https://relishapp.com/rspec/
I'd prefer not to show an example that the usage offrozen_string_literalmakes sense or difference for spec files, as I haven't seen any evidence of that. -
End-to-end tests of our code
Is there a good reason to explicitly specify the already default non-frozen string literal in our own tests?
Was the current doc causing a confusion of some kind?
There was a problem hiding this comment.
Thanks for letting me know the cucumber role in this project.
Personally I don’t have any problem. So I will left from this issue!
|
Thanks for understanding. |
I understand this PR just updates documentations part of #997