> On Oct 10, 2011, at 8:17 PM, Patrick J. Collins wrote:
>
> > I know I can do:
> >
> > blah.should be_empty
> >
> > or
> >
> > blah.should have_key(:to_my_house)
> >
> > ...
> >
> > But, is there a way to do:
> >
> > str = "lmaonade omg rotfcopter!"
> >
> > str.should start_with("lmao")
> >
> > Or is it just best to do:
> >
> > str.starts_with?("lmao").should be_true
>
> See
>
> https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers/be-matchers
>
> and
>
> https://www.relishapp.com/rspec/rspec-expectations/docs/custom-matchers/define-matcher
>
I see... So, the question I have now is, would some argue that defining custom
matchers is not the best thing to do because it results in obfuscated test
behavior which could result in false positives / funky breakage where one might
not think to look?
For example, one of my models has a method:
def alert_flag?
flag == FLAG_VALUES[:alert]
end
...
Having a spec that does:
@my_model.alert_flag?.should be_true
Seemed a little goofy to me... So I did:
RSpec::Matchers.define :have_alert_flag do
match do |actual|
actual.alert_flag?
end
end
So that I can do:
@my_model.should have_alert_flag
... But then I got a little worried about the fact that this creates more
magic in my test, makes things less clear for other developers who might not
know what custom matchers are, etc..
Are these valid concerns? Or should I just keep making custom machers like
this?
As always, thanks for the guidance!
Patrick J. Collins
http://collinatorstudios.com
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
