We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
A way to solve this forum request
Currently, when validating the type of a value in spec, we need to restrict the type afterwards in order to call restricted methods on the sample:
index = "foo".index('o') index.should_not be_nil foo[index.not_nil!].should eq('o')
The not_nil! is needed because the compiler has no way to know that the should_not be_nil means that index will not be nil.
not_nil!
should_not be_nil
index
nil
The idea is to let be_nil and be_a expectations return the value with appropriate type restriction:
be_nil
be_a
index = "foo".index('o') index = index.should_not be_nil foo[index].should eq('o')
Basically, the result of obj.should_not be_nil will return obj as a non-nil object.
obj.should_not be_nil
obj
The same applies for obj.should be_a(T) and obj.should_not be_a(T).
obj.should be_a(T)
obj.should_not be_a(T)
An implementation was submitted in #8240, but it should be overhauled.
The text was updated successfully, but these errors were encountered:
Successfully merging a pull request may close this issue.
A way to solve this forum request
Currently, when validating the type of a value in spec, we need to restrict the type afterwards in order to call restricted methods on the sample:
The
not_nil!
is needed because the compiler has no way to know that theshould_not be_nil
means thatindex
will not benil
.The idea is to let
be_nil
andbe_a
expectations return the value with appropriate type restriction:Basically, the result of
obj.should_not be_nil
will returnobj
as a non-nil object.The same applies for
obj.should be_a(T)
andobj.should_not be_a(T)
.An implementation was submitted in #8240, but it should be overhauled.
The text was updated successfully, but these errors were encountered: