[mocha-developer] how does Mocha compare in terms of classical vs mock-based testing, and stubbing???
greg.hauptmann.ruby at gmail.com
Mon Feb 5 15:10:19 EST 2007
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
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
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"?
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
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?
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?
development mode code insertion
On 2/5/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 2/4/07, Greg Hauptmann <greg.hauptmann.ruby at gmail.com> wrote:
> > Hi guys,
> > I've just been reading Martin Fowler's article re mock versus
> > stubbing<http://martinfowler.com/articles/mocksArentStubs.html>where
> > he compares traditional TDD testing techniques with mock based
> > testing. I'd be interested in comments from a ruby on rails perspective
> > terms of this and Mocha? For example:
> > a) Do you see Mocha as a robust way to test Ruby on Rails based apps?
> Yes - though I think of mocking as one tool among many in a robust
> > b) Why would one use Mocha over traditional non-mock object based
> > for Ruby on Rails?
> Interface Discovery!!!!!! Read http://jmock.org/oopsla2004.pdf for
> more info on that.
> > c) Is Mocha a good choice for stubbing out other components that the
> > app may interact with, for the purpose of testing?
> Short version: Yes.
> Longer version: A guideline that I like to follow is to wrap 3rd party
> APIs with thin adapters that provide context-appropriate method names
> and only those that your app needs. Then you mock your own API, not
> the 3rd party API. You still need to test your adapter, but that test
> is isolated from the tests that are about your application and what it
> > Tks
> > Greg
> > _______________________________________________
> > mocha-developer mailing list
> > mocha-developer at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mocha-developer
> mocha-developer mailing list
> mocha-developer at rubyforge.org
More information about the mocha-developer