mock framework

[Jim Weirich-2]

On Aug 22, 2007, at 4:43 PM, David Chelimsky wrote:
> The problem w/ mixing mocking frameworks is that some of them (namely
> rspec and mocha) add methods to Object, and they use similar methods
> (like mock()) to create mocks. So you can only safely have one mock
> framework PER PROCESS, not per file.

FlexMock will safely mix with Mocha (under Test::Unit).  I believe  
(without actually trying) that FlexMock will mix with the RSpec Mock  
as well with the restriction you have to explicitly validate the  
FlexMock mocks at the end of the spec.  (Since RSpec doesn't have the  
facility to use two mock frameworks invisibly).

--
-- Jim Weirich
-- jim.weirich@...




_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

[Zach Dennis-2]

On 8/23/07, Dan North <dan@...> wrote:

>
>  David Chelimsky wrote:
>  On 8/22/07, Scott Taylor <mailing_lists@...> wrote:
>
>
>  On Aug 22, 2007, at 3:26 PM, Dan North wrote:
>
>
>
>  One potential issue is the one-mocking-framework-per-run
> constraint. In other words, any future development of rspec would
> have to continue to use the rspec mocking framework because we
> couldn't suddenly start using mocha mocks (say) in new examples.
>
> This isn't a big deal for now, but it would be if we started
> wanting to mock things that rspec's built-in mocking framework
> couldn't handle.
>
> However it pans out, we will be implicitly "preferring" whichever
> framework rspec itself uses for describing its own behaviour. Of
> course this would become moot if we could choose a mocking
> framework per describe block (maybe using a stack that gets popped
> at the end of the describe block).
>
>  I believe it's a good option to factor out the mocking framework.
> Why couldn't it just be a dependency on the rspec gem, and use it as
> the default, as it is now? If one wants to use another mocking
> framework, they can - that is the state of things right now (AFAIK).
>
> But I think the docs should be clear about this - that doing bdd w/
> out mocks & stubs shouldn't be an option.
>
> As for using multiple mock frameworks on one project - is that
> currently an option? Couldn't different spec_helper.rb files be
> included for different mocking frameworks?
>
>  The problem w/ mixing mocking frameworks is that some of them (namely
> rspec and mocha) add methods to Object, and they use similar methods
> (like mock()) to create mocks. So you can only safely have one mock
> framework PER PROCESS, not per file.
>
>  I would suggest that you only want one mocking framework per project
> anyway, for the sake of sanity. Surely that comes under common coding
> conventions?!
>
>  Cheers,
>  Dan
>
>

We use two mocking frameworks. Hardmock and Mocha. In some places we
want strict ordered mocks. In other places we don't care and we want
stubbing (which Mocha has and Hardmock doesn't).

They place nice together.

Zach
_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

[Michael Klishin-4]

Most people use what is by default. Others do not care whether there is
a default framework, they use what they like or need. So I find process
of making decision on this endless.

You may add an option to rspec generator and raise an exception if user
do not specify what mocking framework to use. You may extract current
one that RSpec uses. All these efforts will be confusing for most of
RSpec users who just want stuff work, not be "vendor neutral".

The only benefit I see is that you can end up using the same framework
Test::Unit does. And yes, you still have to use something by default
(people will be telling you you prefer it, think about it). This will
make a transition from T::U to RSpec a bit easier.

In the long run this is a useless move to me. We're better concentrate
on RBehave merging and so forth.

David Chelimsky wrote:
> One thing I do NOT want to do is have RSpec prefer one framework over
> another.
>
> Thoughts?

--
MK
_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

[David Chelimsky-2]

On 8/24/07, Michael Klishin <michael.s.klishin.lists@...> wrote:

> Most people use what is by default. Others do not care whether there is
> a default framework, they use what they like or need. So I find process
> of making decision on this endless.
>
> You may add an option to rspec generator and raise an exception if user
> do not specify what mocking framework to use. You may extract current
> one that RSpec uses. All these efforts will be confusing for most of
> RSpec users who just want stuff work, not be "vendor neutral".
>
> The only benefit I see is that you can end up using the same framework
> Test::Unit does.

Huh? Test::Unit does not use any mock framework that I'm aware of.

> And yes, you still have to use something by default
> (people will be telling you you prefer it, think about it). This will
> make a transition from T::U to RSpec a bit easier.
>
> In the long run this is a useless move to me.

For me, maintaining RSpec's mocking framework, which does have feature
requests and bug reports from time to time, is more burden on the
project over the long haul than a bit of pain right now. And it really
doesn't add any value over mocha or flexmock. If it did, that would be
a different story. But I'd rather see our efforts focused on improving
things that are unique to RSpec.

So I don't see this as a useless exercise at all.

> We're better concentrate
> on RBehave merging and so forth.

That's certainly higher priority. Good point. But that doesn't mean it
has to be exclusive of other initiatives.

Cheers,
David

>
> David Chelimsky wrote:
> > One thing I do NOT want to do is have RSpec prefer one framework over
> > another.
> >
> > Thoughts?
>
> --
> MK
> _______________________________________________
> rspec-devel mailing list
> rspec-devel@...
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel