stub since it's less fragile and more intention revealing. I no longer feel as I did when I wrote this entry, but I've left it for historical reasons. Related reading here.I've previously written about using Mocks and Stubs convey intent. When I was using C#, I believed this was the best solution for creating robust tests. These days, all my code is written in Ruby. Making the switch to Ruby provided another example that reinforces an assertion I've heard before: Best Practices are so context dependent it's dangerous to use the term.
Here's the reason I no longer feel as I did when I created the above entry: When using Mocha to mock or stub behavior, I can't think of a reason I would ever want to use SomeObject.stubs(..) instead of SomeObject.expects(..). The closest I could come to a reason was that
stubs will allow an arbitrary number of calls to the same method. However, I don't believe that's a good enough reason since I can also use SomeObject.expects(:a_method).at_least_once.The problem with using SomeObject.stubs is that it's almost the same as using SomeObject.expects, except if it's no longer necessary it doesn't cause a test to fail. This can lead to tests that unnecessarily stub methods as the application's implementation changes. And, the more methods that require stubbing the less the test can concisely convey intent.
I'm not asserting that you should never use SomeObject.stubs, but I do believe it's smarter to favor SomeObject.expects if you are concerned with keeping your test suite well maintained.
Of course, none of this is related to creating actual stubs for your tests. I still believe it's wise to create stub object instances for classes that are required for a unit test, but are not the class under test. For example, if I were testing a mapper class, I would use a stub for the objecting being mapped.
test "an order's id is mapped to the request object" doI use a stub in the above example because I don't want to couple the test to the implementation of an order. I believe this creates a more robust, maintainable test
request = OrderServiceMapper.create_request(stub(:id=>1, ...))
assert_equal 1, request.order_id
end
what is this expects() method?
ReplyDeleteIf you use Mocha for mocks and stubs it adds and expects() method to every object. Therefore you can add an expectation to an instance:
ReplyDeletefoo = Foo.new
foo.expects(:bar)
foo.bar # expectation verified
or, you can add an expectation to the class itself:
Foo.expects(:bar)
Foo.bar # expectation verified
One thing that bugs me about Mocha is that it doesn't keep strict ordering when using expects.
ReplyDeleteThere are tests in the the Mocha test suite which explicitly verify that strict ordering doesn't work.
I don't see why you wouldn't want ordering as it makes tests more readable, and it provides better developer documentation.
I can't recall using stub() outside of an example like the one you've posted although I typically assign "order = stub(:id=>1)" and passing "order" in rather then passing the stub in directly to the method you're testing.