[mocha-developer] how does Mocha compare in terms of classical vs mock-based testing, and stubbing???

James Mead jamesmead44 at gmail.com
Tue Feb 6 05:35:45 EST 2007

On 05/02/07, Greg Hauptmann <greg.hauptmann.ruby at gmail.com> wrote:
> I'll read through the references.  I'm getting that same feeling I had
> when
> I came across blocks for the 1st time in ruby actually :) [I still wonder
> if
> I truly understand the full power of blocks and whether I'm missing
> something]   I think perhaps I need to write/use the framework to have it
> sink in.

I think that's very true. I'm still learning how to improve my TDD and
mocking techniques. I find a mixture of reading and trying things out is the
best way to learn. Don't be daunted by all the articles about mocking and
interaction based testing - there's never a right and wrong way - just
better and worse ways ;-)

In the meantime if you had a few minutes for a couple of followup
> questions.  Actually I'll just focus around my stubing-out-paypal
> requirement:
> So the suggestion is to have (a) a thin paypal adaptor to stub out the
> interface, (b) use of mocha for testing the interface.
> Q1 - Was there a specific ruby on rails pattern/approach you had in mind
> when you mentioned "adaptor"?

Not really - I was thinking of an "adapter" in fairly general terms. An
adapter could be useful to simplify the interface to the external service
e.g. you may not need all the flexibility of a 3rd party library. An adapter
can also be useful to decouple your application from a particular 3rd party
library - it's much better to mock/stub your own code (i.e. the adapter) and
not 3rd party code which may be subject to change. So an adapter is not
essential, but gives these advantages.

Q2 - Is the purpose of the components suggested per the below, i.e. do I
> have it right.  Use cases:
> Testing the application
> (a) ability to manually test app - uses paypal adaptor
> (b) ability to run state based unit tests - uses paypal adaptor
> (c) ability to run mocha tests within the unit testing framework - My
> understanding here is that Mocha wouldn't actually use the adaptor?  i.e.
> looking at the examples it seems with Mocha you would treat the paypal
> adaptor as a collaborator and effectively build the understanding of how
> it
> behaves manually yourself into your Mocha test code?  (not sure if this is
> DRY - maybe I'm missing something)
> Testing the Paypal interface
> (d) well I guess in terms of testing the Paypal interface this isn't what
> we're focusing on here.   However it is an interesting question.  It would
> have to be a test cases that run only in the non-development environment
> when the system is deployed to production (i.e. so Paypal can call back to
> my app)

Hmm - I'm a bit confused by all the above. In tests for the application I
would replace the adapter with a mock object and either expect or stub
method calls.

Q3 - What method would you recommend in a situation where some test cases (
> i.e. the final Paypal interface focused unit tests) should only run in one
> particular environment.  I did see an article in the past from memory
> which
> highlighted a ruby on rails approach for loading specific code based on
> which environment one was in.  Perhaps I should dig this up?

I'm not sure what you're getting at here. I think you might be talking about
the normal "Rails mocks"  approach i.e. alternative Fake Object definitions
of particular classes which are loaded in preference to the real definitions
in a particular environment. These are the classes you can put in the
test/mocks directory.

Q4 - This was buried in Q2 probably, but just confirming: The Mocha based
> tests don't actually run code within the collaborator do they?  i.e.
> rather
> they seem to build up the expected responses from the collaborator that
> the
> SUT (system under test) will see once the test is initiated?

Again, I'm not 100% sure I understand you correctly, but I think the answer
is yes!

At the risk of sounding like a broken record, I really recommend diving in
and having a go - conversations like this one tend to suffer from ambiguity
of language on both sides and so often go around in circles. Concrete
examples are worth a lot of words! If you get stuck or are unhappy about a
particular test, post it here and we'll try to help you.


More information about the mocha-developer mailing list