@dimroc => long overdue, some quacking improvements #42

merged 3 commits into from Jul 3, 2013


None yet

2 participants

dblock commented Jul 2, 2012

Based on your last comments, it's basically a bit of cleanup in the RSpec topic.


The quack invocation here would not be on the duck instance but would instead reside in the test's scope

duck.should respond_to :quack

I could be erring on the side of pedantic, but if quack returns nil or false, this test would be a false positive. There are other corner cases too.

Should we propose the following:

# Unit Test
assert Duck.new.responds_to?(:quack)

# RSpec
Duck.new.should.respond_to :quack
dimroc commented on 21d57cd May 9, 2012

Left some comments inline on a few of the assertions. The main issue is that "quack" isn't an RSpec matcher nor would it be one even in the analogy. I've inserted respond_to as a potential matcher.

So if I add an actual RSpec matcher like should_quack the code would make sense?

When asserting against a value, I believe you can only use should or should_not to prepare the invocation of an rspec matcher. should in of itself is not the RSpec matcher. After should is when you would place your matcher, such as be_nil, have_content or validates_presence_of. If you have your own RSpec matcher, it would probably be called has_quack and would test for the presence of the quack method on the object.

This would be identical to

duck.should respond_to(:quack)

You wouldn't want to call your matcher should_quack because then you'd have to type:

duck.should should_quack



space after should instead of period.

duck.should respond_to :quack
dblock commented Jul 3, 2012

Ouch, fixed.

@dblock dblock merged commit a34dc7c into generalassembly:master Jul 3, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment