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
Avoid be_falsey and be_truthy #2736
Conversation
16bb232
to
ee33397
Compare
Notes: * no idea why the `remove_method` is needed now and wasn't needed previously * no spec failure as specs use `be_falsey` and `be_truthy`
ee33397
to
e961660
Compare
Warning text that includes file paths was cut off when a spec was failing due to a Ruby warning.
We define the reader as a method down the lines anyway. core_spec was issuing a warning that this method is redefined.
`define_aliases` actually only defined one. `define_predicate_for` was always passed a single argument.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I dared to push a small fix for profile_examples
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm convinced.
Also, wonderful branch name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems these changes cause enough of a shift in our public api to break rspec-rails specs?
I've left some feedback that needs addressing as well...
@@ -14,18 +14,14 @@ Feature: custom settings | |||
expect(RSpec.configuration.custom_setting).to be_nil | |||
end | |||
|
|||
it "acts false by default" do | |||
expect(RSpec.configuration.custom_setting).to be_falsey | |||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is part of the documentation, not a copy of another spec so should be restored.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed it thinking that:
be_falsey
should not be encouraged- it is completely redundant with the previous spec (impossible to pass this and not pass the previous spec)
- it does not document in any way
custom_setting
, only that we can alwaysexpect(nil).to be_falsey
@@ -296,16 +296,16 @@ | |||
end | |||
|
|||
describe "--fail-fast" do | |||
it "defaults to false" do | |||
expect(parse_options[:fail_fast]).to be_falsey | |||
it "defaults to nil" do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These concern me as they represent a change in how we document them, if they are wrong I almost want to fix them rather than the specs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't check the implementation, but I find it perfect that the setting is nil
if there's no CLI option, and 1
or false
if there's an explicit CLI option. For example it makes it possible to override a nil
setting with a local setting file, but false
should not be overriden.
Or are you talking about 1
vs true
?
Yes, the rspec-rails have a few tests for "Configuration adds settings '...'" which now have errors because the predicates now return IMO these tests should consider that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
RSpec Rails failures seem to be mostly caused by the change of what predicates return now !!value
.
They shouldn't expect a nil
where it's actually a false
.
I'll take a stab at fixing tomorrow.
Predicate methods typically return true or false, and should only exist for the uncountable and discrete, e.g. `use_transactional_fixtures?`, but not `max_formatted_output_length?`. This relates to changes made in rspec/rspec-core#2736
Fixed the spec in RSpec Rails, but it fails there because it depends on |
😆 if you want, you could commit an intermediate step with |
We prefer to be on the safe side. |
I propose to merge this despite underlying That RSpec Rails PR is red since its specs expect predicate methods to return a boolean. Before this change, they were returning the same value as the reader (which doesn't make much sense to me). |
Predicate methods typically return true or false, this is part of an associated bug-fix in rspec/rspec-core#2736 but as rspec-rails is now a separate entity we must account for this ourselves. Note some predicates are here by default settings and may be able to be tidied up in `rspec-rails` 5.
Predicate methods typically return true or false, this is part of an associated bug-fix in rspec/rspec-core#2736 but as rspec-rails is now a separate entity we must account for this ourselves. Note some predicates are here by default settings and may be able to be tidied up in `rspec-rails` 5.
Avoid be_falsey and be_truthy
…e_to_yourself Avoid be_falsey and be_truthy --- This commit was imported from rspec/rspec-core@97a6f23.
This commit was imported from rspec/rspec-core@e52f25b.
This PR first fixes
Configuration#any_predicate?
to returntrue
/false
instead ofany_predicate
.No spec fail for this change, because all specs on those predicates use
be_truthy
, like this one which passed even thoughconfig.custom_option?
used to be a simple alias forconfig.custom_option
and return'a value'
.Second commit removes all uses of
be_truthy
andbe_falsey
except the two for testing the matchers themselves. I believe most of these date from before they were renamed to avoid confusionMost of these changes are trivial
be_truthy => be(true)
. A non-trivial example is this spec that was not updated now thatfail-fast
defaults to1
instead oftrue
.