Newbie here and I’m using rspec with jruby to test a java class, but
this is
more of a rspec question.
I have a java HashMap object and want to make sure a key exists. I
have this as
my test:
context :toHashMap do
subject { @var_list.toHashMap }
it { should satisfy{|a| a.contains_key?(var1) } }
it { should satisfy{|a| a.contains_key?(var2) } }
it { should satisfy{|a| a.contains_key?(var3) } }
end
@var_list is set to another java object that has a method toHashMap
that returns
a HashMap. var1, var2 and var3 are set using let(:var1), etc. If the
one of
these fails, I get this telling me that I need to supply a description
method:
'Java::LibraryLanguage::XmlVariableList when added duplicate variables
with
different values toHashMap should When you call a matcher in an
example without
a String, like this:
specify { object.should matcher }
or this:
it { should matcher }
RSpec expects the matcher to have a #description method. You should
either
add a String to the example this matcher is being used in, or give it
a
description method. Then you won’t have to suffer this lengthy warning
again.
’ FAILED
expected {var01=2, var02=this-is-a-string} to satisfy block
<<<<<<<
I’d like to put 'contain the key ’ in place of ‘When you call a
matcher in
an example without a String’
Where do I put that string? I thought I could just do:
it “should contain the key #{var1}” { should satisify{|a|
a.contains_key?(var1)
} }
But, the loading complains on that. Where can a put a custom
description into
this code (easily/polite way).
But, the loading complains on that. Where can a put a custom
description into
this code (easily/polite way).
Congratulations - you’re apparently the first person to ever use the
satisfy matcher with an implicit subject, and have uncovered a bug!
I’d recommend not using that satisfy matcher for this case though, as
it’s really intended to be more of a last resort, and you can do much
better with a custom matcher:
RSpec::Matchers.define :contain_key do |key|
match do |subject|
subject.contains_key?(key)
end
end
Then you can say:
context :toHashMap do
subject { @var_list.toHashMap }
it { should contain_key(var1) }
it { should contain_key(var2) }
it { should contain_key(var3) }
That helped a lot and I see it is a better/more polite 1-liner-way.
Do you recommend that these custom matchers probably need to go into a
spec helper for standard java classes and included since contains_key?
(key) maps to the java HashMap method containsKey(key)? Do I put
these in a ruby module to be included?
That helped a lot and I see it is a better/more polite 1-liner-way.
Do you recommend that these custom matchers probably need to go into a
spec helper for standard java classes and included since contains_key?
(key) maps to the java HashMap method containsKey(key)? Do I put
these in a ruby module to be included?
[I moved your responses to the bottom. Please use bottom or inline
posting rather than top posting. ]
The convention is to have a line like this in spec/spec_helper.rb:
I have a java HashMap object and want to make sure a key exists. I @var_list is set to another java object that has a method toHashMap
specify { object.should matcher }
again.
it “should contain the key #{var1}” { should satisify{|a|
Or am I missing something? Or is that just not desirable? I know I
can use rake and create a rake task(s), but from the perspective of
the command line, it would be nice to not to have to supply the -r
option unless you want to include something “outside” of this
convention.
For rails and non-rails apps/libs the convention is to have each
*_spec.rb file require the ‘spec_helper’ at the top of the spec like so:
By following this convention you will only have to specify the spec on
the command line.
RSpec.configure do |c|
c.include CustomMatchers
end
Okay, 1 more question and maybe this is more of a convention request.
I know in my rails apps that my environment is loaded when running my
specs from a rake task or from the spec command. But for a non-rails
app, it would be nice to default spec program to load spec_helper if
it exists in the spec dir. Like:
jruby -S spec spec
instead of having to do this to include the spec_helper every time:
jruby -S spec -r spec/spec_helper.rb spec
Or am I missing something? Or is that just not desirable? I know I
can use rake and create a rake task(s), but from the perspective of
the command line, it would be nice to not to have to supply the -r
option unless you want to include something “outside” of this
convention.
Regards,
GregD
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.