I want my class Reader to loop on the content of its Stack until false
is
returned. I also want an optional argument to exist that limits how many
times the stack will be read, even if some elements are left. I was
trying
to spec this last bit but ended up on a false positive.
Hope the example will be clear enough:
#spec_reader.rb
describe Reader do
it “should stop reading items when called with a limit” do @stack = mock(Stack)
Stack.should_receive(:new).and_return(@stack)
@reader = Reader.new @reader.read_stack(3)
end
end
reader.rb
class Reader
def initialize @stack = Stack.new
end
def read_stack(limit = 0) #0 = read until false is returned
while val = @stack.read
Not implemented on purpose!
return if limit == 0
limit -= limit
…
end
end
So the test should fail, because the use of the limit argument has not
been
implemented yet and #read gets called 7 times. But the test actually
passes.
I looked into it a bit and it seems that number of arguments in #and_return
overrides the arguments of #exactly.
Did I misunderstand the point of #exactly or should I build my code
differently so that the value returned by #and_return does not influence
how
many times #read is called?
end
So the test should fail, because the use of the limit argument has not been
implemented yet and #read gets called 7 times. But the test actually passes.
I looked into it a bit and it seems that number of arguments in #and_return
overrides the arguments of #exactly.
Did I misunderstand the point of #exactly or should I build my code
differently so that the value returned by #and_return does not influence how
many times #read is called?
I think this is a bug, but the question is - what is the bug? I think
the mock should complain when you set exactly(n).times and then give
it a different number of return values.
Yes this would make sense, or the mock could just stop sending the
values as
soon as it does not receive messages anymore.
Obviously I prefer this second behaviour because it would, I think, make
my
specs work correctly. But from a logical point of view as well, this
works
for me. If the mock complains when there’s more return values than
expected
calls, it would reduce the amount of errors, but it’s usually a
one-liner so
the risk is not that great. On the other hand the second possibility
(just
stop sending values) would introduce a flexibility that might be handy
in
some situations.
I’m quite a beginner in both ruby and TDD/BDD concepts so I feel like
there’s a lot I just don’t have a full grasp on anyway.
Regarding my specs do you think I should structure the whole thing
differently?
David C.-2 wrote:
Hope the example will be clear enough:
end
So the test should fail, because the use of the limit argument has not
many times #read is called?