Comments on: Mocking with Ruby - a question of syntax http://www.magpiebrain.com/blog/2005/06/19/mocking-with-ruby-a-question-of-syntax/ Sam Newman's blog Sat, 05 Jul 2008 00:44:53 +0000 http://wordpress.org/?v=2.5.1 By: James Mead http://www.magpiebrain.com/blog/2005/06/19/mocking-with-ruby-a-question-of-syntax/#comment-2879 James Mead Fri, 01 Sep 2006 18:09:33 +0000 http://www.magpiebrain.com/2005/06/19/mocking-with-ruby-a-question-of-syntax/#comment-2879 "Mocha":http://mocha.rubyforge.org builds on SchMock and allows you to mock methods on real (non-mock) objects and classes. Mocha builds on SchMock and allows you to mock methods on real (non-mock) objects and classes.

]]> By: Ben Griffiths http://www.magpiebrain.com/blog/2005/06/19/mocking-with-ruby-a-question-of-syntax/#comment-779 Ben Griffiths Sun, 26 Jun 2005 17:45:50 +0000 http://www.magpiebrain.com/2005/06/19/mocking-with-ruby-a-question-of-syntax/#comment-779 Schmock (http://rubyforge.org/projects/schmock/) is a very simple ruby mocking implementation that we knocked together in developing our apps. Nothing special, but a bit like jmock. Schmock (http://rubyforge.org/projects/schmock/) is a very simple ruby mocking implementation that we knocked together in developing our apps. Nothing special, but a bit like jmock.

]]> By: Nat http://www.magpiebrain.com/blog/2005/06/19/mocking-with-ruby-a-question-of-syntax/#comment-778 Nat Mon, 20 Jun 2005 16:57:52 +0000 http://www.magpiebrain.com/2005/06/19/mocking-with-ruby-a-question-of-syntax/#comment-778 I would prefer the returns stuff to be outside the block. E.g.: expect 1 { m.do_something() }.returns 10 expect (at_least 1) { m.do_something_else() }.returns 20 That makes the expected call really distinct from the action. I don't care about typing expect more than once if the resulting code is easier to read. I would prefer the returns stuff to be outside the block. E.g.:

expect 1 { m.do_something() }.returns 10
expect (at_least 1) { m.do_something_else() }.returns 20

That makes the expected call really distinct from the action.

I don’t care about typing expect more than once if the resulting code is easier to read.

]]> By: Sam Newman http://www.magpiebrain.com/blog/2005/06/19/mocking-with-ruby-a-question-of-syntax/#comment-777 Sam Newman Mon, 20 Jun 2005 10:40:54 +0000 http://www.magpiebrain.com/2005/06/19/mocking-with-ruby-a-question-of-syntax/#comment-777 The _syntax_ (as far as Ruby goes) is fine - the problem is the implementation. With your second example, how to you determine which mock is having the expectations defined on it? The idea of having the mock _inside_ the expectaion block is so you can then have a single expectation block for your test. If having such a block doesn't help readability (or the implementation is too complex), then I'd favour your first example. The syntax (as far as Ruby goes) is fine – the problem is the implementation. With your second example, how to you determine which mock is having the expectations defined on it? The idea of having the mock inside the expectaion block is so you can then have a single expectation block for your test. If having such a block doesn’t help readability (or the implementation is too complex), then I’d favour your first example.

]]> By: Stuart http://www.magpiebrain.com/blog/2005/06/19/mocking-with-ruby-a-question-of-syntax/#comment-776 Stuart Mon, 20 Jun 2005 09:26:15 +0000 http://www.magpiebrain.com/2005/06/19/mocking-with-ruby-a-question-of-syntax/#comment-776 I've been having great fun in work recently playing around with the way we write tests, and as my colleague Mike said, developers spend more time reading code than writing it. Hence it makes sense to use the more readable approach to your mocking framework. Whilst I use JMock and find it by far the best mock object implementation out there... I still find it has rather a lot of fluff around it. Particularly when more than one method call is made to an object. With that said, I'd be tempted by the last syntax, except that I'd pull the mock object out hence: mock1.expect{ halve(eq(10)).returns(5) } however, it may be made more readable by using something similar to your first effort: expect { :given => 10, :halve, :returns => 5 } I've never coded Ruby, so forgive me if any of the syntax is incorrect, but I hope it kind of still makes sense. I’ve been having great fun in work recently playing around with the way we write tests, and as my colleague Mike said, developers spend more time reading code than writing it. Hence it makes sense to use the more readable approach to your mocking framework.

Whilst I use JMock and find it by far the best mock object implementation out there… I still find it has rather a lot of fluff around it. Particularly when more than one method call is made to an object.

With that said, I’d be tempted by the last syntax, except that I’d pull the mock object out hence:

mock1.expect{

halve(eq(10)).returns(5)
}

however, it may be made more readable by using something similar to your first effort:

expect {

:given => 10,
:halve,
:returns => 5
}

I’ve never coded Ruby, so forgive me if any of the syntax is incorrect, but I hope it kind of still makes sense.

]]>