Based on your last comments, it's basically a bit of cleanup in the RSpec topic.
Fixed duck quacking.
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
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
You wouldn't want to call your matcher should_quack because then you'd have to type:
space after should instead of period.