On 21/01/2008, Jay Fields <jay at jayfields.com>
wrote:>
> I try to set only one expectation per test, but I also dislike having
> extra stub declarations that are no longer used, thus I often find
> myself wanting Object.expects(:foo).at_least_once. That works, but I
> don''t actually "expect" foo to be called, in fact, I
don''t care, I
> only want to know when it isn''t called so I can remember to clean
up
> the test. Since I don''t "expect" foo, it''s also
quite verbose for my
> purpose.
>
> Given the above, I''d really like a .stubs! method. The .stubs!
method
> would convey that this is a stub and is unimportant for the test;
> however, if you don''t call the method at least once, it will
remind
> you to remove the stub.
>
> I also think that stubs! is appropriate given that the intended use
> of ! methods is "the dangerous version of a method". I''d
say a stub
> that raises an exception if it''s never called is definitely the
> dangerous version of the method.
>
> Thoughts?
>
On 21/01/2008, Jay Fields <jay at jayfields.com>
wrote:>
> I try to set only one expectation per test, but I also dislike having
> extra stub declarations that are no longer used, thus I often find
> myself wanting Object.expects(:foo).at_least_once. That works, but I
> don''t actually "expect" foo to be called, in fact, I
don''t care, I
> only want to know when it isn''t called so I can remember to clean
up
> the test. Since I don''t "expect" foo, it''s also
quite verbose for my
> purpose.
>
> Given the above, I''d really like a .stubs! method. The .stubs!
method
> would convey that this is a stub and is unimportant for the test;
> however, if you don''t call the method at least once, it will
remind
> you to remove the stub.
>
> I also think that stubs! is appropriate given that the intended use
> of ! methods is "the dangerous version of a method". I''d
say a stub
> that raises an exception if it''s never called is definitely the
> dangerous version of the method.
>
> Thoughts?
>
Coincidentally, I''ve been playing with generating a warning in this
scenario. My initial reaction to your suggestion is that I''d rather not
add
more clutter to the main API if the warning solution is good enough, but
I''d
be interested to hear what others think. If a warning isn''t sufficient,
perhaps we could have different levels of behaviour - relaxed, warning,
paranoid - which do nothing, print a warning, or raise an exception
respectively.
Incidentally, I was thinking of doing something similar for when setting an
expectation on a non-mock object which doesn''t implement that method
(or its
not public). I''d be interested in your thoughts on that too.
--
James.
http://blog.floehopper.org
http://tumble.floehopper.org