From jeremy.burks at gmail.com  Wed Nov 15 11:23:47 2006
From: jeremy.burks at gmail.com (Jeremy Burks)
Date: Wed, 15 Nov 2006 10:23:47 -0600
Subject: [mocha-developer] using expects with [] (for Hash and Array)
Message-ID: <fa870e440611150823q10b64e8dh7d8e9d3cc339cbd3@mail.gmail.com>

First off, thanks for the great library.

Is there a way setup expects with this:

    runtime_options[:property] = properties_option_string

or do i have to use:

    runtime_options.store(:property, properties_option_string)

which results in this:

    runtime_options.expects(:store).with(:property, 'prop1=1')


Thanks for your help.
jeremy

From jamie.macey at gmail.com  Wed Nov 15 16:07:59 2006
From: jamie.macey at gmail.com (Jamie Macey)
Date: Wed, 15 Nov 2006 13:07:59 -0800
Subject: [mocha-developer] using expects with [] (for Hash and Array)
In-Reply-To: <fa870e440611150823q10b64e8dh7d8e9d3cc339cbd3@mail.gmail.com>
References: <fa870e440611150823q10b64e8dh7d8e9d3cc339cbd3@mail.gmail.com>
Message-ID: <beca44380611151307tba616d9r7a25d134c42f912e@mail.gmail.com>

On 11/15/06, Jeremy Burks <jeremy.burks at gmail.com> wrote:
> First off, thanks for the great library.
>
> Is there a way setup expects with this:
>
>     runtime_options[:property] = properties_option_string

This is probably equivalent to

    runtime_options.[]=(:property, properties_option_string)

in which case, this should work:

    runtime_options.expects(:[]=).with(:property, properties_option_string)

- Jamie

From jamesmead44 at gmail.com  Wed Nov 15 17:06:59 2006
From: jamesmead44 at gmail.com (James Mead)
Date: Wed, 15 Nov 2006 22:06:59 +0000
Subject: [mocha-developer] using expects with [] (for Hash and Array)
In-Reply-To: <fa870e440611150823q10b64e8dh7d8e9d3cc339cbd3@mail.gmail.com>
References: <fa870e440611150823q10b64e8dh7d8e9d3cc339cbd3@mail.gmail.com>
Message-ID: <1db558f00611151406h3ef4f539q2a3c3485959de545@mail.gmail.com>

On 15/11/06, Jeremy Burks <jeremy.burks at gmail.com> wrote:
>
> First off, thanks for the great library.
>
> Is there a way setup expects with this:
>
>     runtime_options[:property] = properties_option_string
>
> or do i have to use:
>
>     runtime_options.store(:property, properties_option_string)
>
> which results in this:
>
>     runtime_options.expects(:store).with(:property, 'prop1=1')
>

[]= is just another method, so you should be able to do something like
this...

runtime_options.expects(:[]=).with(:property, 'prop1=1')

-- 
James.
http://blog.floehopper.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mocha-developer/attachments/20061115/333f7d32/attachment.html 

From jeremy.burks at gmail.com  Wed Nov 15 18:02:50 2006
From: jeremy.burks at gmail.com (Jeremy Burks)
Date: Wed, 15 Nov 2006 17:02:50 -0600
Subject: [mocha-developer] using expects with [] (for Hash and Array)
In-Reply-To: <1db558f00611151406h3ef4f539q2a3c3485959de545@mail.gmail.com>
References: <fa870e440611150823q10b64e8dh7d8e9d3cc339cbd3@mail.gmail.com>
	<1db558f00611151406h3ef4f539q2a3c3485959de545@mail.gmail.com>
Message-ID: <fa870e440611151502u29c86e0i4d5d7af2db375b84@mail.gmail.com>

Aahhhh, yes. That makes sense now that i am looking at it.

Thanks.
jeremy

On 11/15/06, James Mead <jamesmead44 at gmail.com> wrote:
> On 15/11/06, Jeremy Burks <jeremy.burks at gmail.com> wrote:
> > First off, thanks for the great library.
> >
> > Is there a way setup expects with this:
> >
> >     runtime_options[:property] = properties_option_string
> >
> > or do i have to use:
> >
> >     runtime_options.store(:property,
> properties_option_string)
> >
> > which results in this:
> >
> >     runtime_options.expects(:store).with(:property,
> 'prop1=1')
> >
>
> []= is just another method, so you should be able to do something like
> this...
>
> runtime_options.expects(:[]=).with(:property, 'prop1=1')
>
> --
> James.
> http://blog.floehopper.org
> _______________________________________________
> mocha-developer mailing list
> mocha-developer at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mocha-developer
>
>

From jason at jasonwatkins.net  Tue Nov 21 13:45:33 2006
From: jason at jasonwatkins.net (Jason Watkins)
Date: Tue, 21 Nov 2006 10:45:33 -0800
Subject: [mocha-developer] stubbing in development environment
Message-ID: <ffc81db0611211045q2e0079cbqbaf034e49d2c3dea@mail.gmail.com>

Hi guys.

Quite happy with mocha for testing. It's been a bit of an eye opener
for me, and I expect to begin using it heavily.

One other thing I'd like to do is stub out particular class methods in
development. Is there a way I can do this with mocha?

Jason

From jamesmead44 at gmail.com  Wed Nov 22 05:07:44 2006
From: jamesmead44 at gmail.com (James Mead)
Date: Wed, 22 Nov 2006 10:07:44 +0000
Subject: [mocha-developer] stubbing in development environment
In-Reply-To: <ffc81db0611211045q2e0079cbqbaf034e49d2c3dea@mail.gmail.com>
References: <ffc81db0611211045q2e0079cbqbaf034e49d2c3dea@mail.gmail.com>
Message-ID: <1db558f00611220207h4fa3e0am8017a00d2872965f@mail.gmail.com>

On 21/11/06, Jason Watkins <jason at jasonwatkins.net> wrote:
>
> Quite happy with mocha for testing. It's been a bit of an eye opener
> for me, and I expect to begin using it heavily.


Cool.

One other thing I'd like to do is stub out particular class methods in
> development. Is there a way I can do this with mocha?
>

Why do you want to do it? Can you give a concrete example?

While it would be technically possible, I wouldn't recommend it.

-- 
James.
http://blog.floehopper.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mocha-developer/attachments/20061122/f2df212e/attachment.html 

From jason at jasonwatkins.net  Wed Nov 22 05:38:45 2006
From: jason at jasonwatkins.net (Jason Watkins)
Date: Wed, 22 Nov 2006 02:38:45 -0800
Subject: [mocha-developer] stubbing in development environment
In-Reply-To: <1db558f00611220207h4fa3e0am8017a00d2872965f@mail.gmail.com>
References: <ffc81db0611211045q2e0079cbqbaf034e49d2c3dea@mail.gmail.com>
	<1db558f00611220207h4fa3e0am8017a00d2872965f@mail.gmail.com>
Message-ID: <ffc81db0611220238u620e50d2t6e0922990990ca68@mail.gmail.com>

Sure. Let's say I have some ruby objects that do i/o with a
distributed system. In the development environment the remote system
isn't available. That gives me two conventional choices:

1.) use a configuration boolean set somewhere to early out
2.) parameterize the constructor to use dependency injection of a mock

Using stubba to override the object directly could be seen as a more
implicit version of #2.

While I understand various folks might object to it on all manner of
philosophical grounds, it's something I'd like to be able to do from
time to time.

Jason

On 11/22/06, James Mead <jamesmead44 at gmail.com> wrote:
> On 21/11/06, Jason Watkins <jason at jasonwatkins.net> wrote:
> > Quite happy with mocha for testing. It's been a bit of an eye opener
> > for me, and I expect to begin using it heavily.
>
> Cool.
> > One other thing I'd like to do is stub out particular class methods in
> > development. Is there a way I can do this with mocha?
> >
>
> Why do you want to do it? Can you give a concrete example?
>
> While it would be technically possible, I wouldn't recommend it.
>
> --
> James.
> http://blog.floehopper.org
> _______________________________________________
> mocha-developer mailing list
> mocha-developer at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mocha-developer
>
>

From jamesmead44 at gmail.com  Wed Nov 22 09:52:41 2006
From: jamesmead44 at gmail.com (James Mead)
Date: Wed, 22 Nov 2006 14:52:41 +0000
Subject: [mocha-developer] stubbing in development environment
In-Reply-To: <ffc81db0611220238u620e50d2t6e0922990990ca68@mail.gmail.com>
References: <ffc81db0611211045q2e0079cbqbaf034e49d2c3dea@mail.gmail.com>
	<1db558f00611220207h4fa3e0am8017a00d2872965f@mail.gmail.com>
	<ffc81db0611220238u620e50d2t6e0922990990ca68@mail.gmail.com>
Message-ID: <1db558f00611220652i4017a199ne526f4d917f86aa1@mail.gmail.com>

On 22/11/06, Jason Watkins <jason at jasonwatkins.net> wrote:
>
> Sure. Let's say I have some ruby objects that do i/o with a
> distributed system. In the development environment the remote system
> isn't available. That gives me two conventional choices:
>
> 1.) use a configuration boolean set somewhere to early out
> 2.) parameterize the constructor to use dependency injection of a mock
>
> Using stubba to override the object directly could be seen as a more
> implicit version of #2.
>
> While I understand various folks might object to it on all manner of
> philosophical grounds, it's something I'd like to be able to do from
> time to time.


I think the objections are more practical than philosophical. If you are new
to mocking, I suggest you read "Mock Roles, not Objects" (
http://www.jmock.org/oopsla2004.pdf by Steve Freeman, Nat Pryce, Tim
Mackinnon, Joe Walnes. Here is a particularly relevant section.

4.1 Only Mock Types You Own
Mock Objects is a design technique so programmers should only
write mocks for types that they can change. Otherwise they cannot
change the design to respond to requirements that arise from the
process. Programmers should not write mocks for fixed types,
such as those defined by the runtime or external libraries. Instead
they should write thin wrappers to implement the application
abstractions in terms of the underlying infrastructure. Those
wrappers will have been defined as part of a need-driven test.
We have found this to be a powerful insight to help programmers
understand the technique. It restores the pre-eminence of the
design in the use of Mock Objects, which has often been
overshadowed by its use for testing interactions with third-party
libraries.

There is nothing to stop you using Mocha in your development environment,
but there are a few issues you should think about...

1) No convenience methods for creating mocks or stubs - you would have to
directly instantiate them using something like Mocha::Mock.new

2) $stubba global variable is not defined - you would have to do something
like $stubba = Mocha::Central.new

3) No auto-verification of expectations - you would have to explicitly call
the verify method on traditional mock/stub objects and $stubba.verify_all to
verify expectations on real objects

4) Probably most importantly, no rolling back of stubbing - you would have
to explicitly rollback by calling $stubba.unstub_all

One of the problems you will run into will be when to call the above hooks
in your development environment.

Some of these hooks are not considered parts of the published API and so are
subject to change.

All the above is written in the context of the HEAD revision in svn  and not
the latest gem.

I hope that makes some kind of sense.
-- 
James.
http://blog.floehopper.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mocha-developer/attachments/20061122/8815c9d3/attachment-0001.html 

From jason at jasonwatkins.net  Wed Nov 22 13:38:16 2006
From: jason at jasonwatkins.net (Jason Watkins)
Date: Wed, 22 Nov 2006 10:38:16 -0800
Subject: [mocha-developer] stubbing in development environment
In-Reply-To: <1db558f00611220652i4017a199ne526f4d917f86aa1@mail.gmail.com>
References: <ffc81db0611211045q2e0079cbqbaf034e49d2c3dea@mail.gmail.com>
	<1db558f00611220207h4fa3e0am8017a00d2872965f@mail.gmail.com>
	<ffc81db0611220238u620e50d2t6e0922990990ca68@mail.gmail.com>
	<1db558f00611220652i4017a199ne526f4d917f86aa1@mail.gmail.com>
Message-ID: <ffc81db0611221038r239e4ccgb8c7433e3e1eecfc@mail.gmail.com>

> I think the objections are more practical than philosophical. If you are new

Right. I wasn't interested in this particular debate.

> Some of these hooks are not considered parts of the published API and so are
> subject to change.

Right. I've gotten this far on my own. My bringing it up is to suggest
that perhaps it should be part of the API.

If you feel "you shouldn't do that, so I'm not going to help you do
it", then another justification would be so that mocha isn't wired so
directly to Test::Unit.

Another example would be exploratory programing.

It looks like I'll just write my own.

Thanks,

Jason

From kkarabuk at thoughtworks.com  Wed Nov 22 17:12:45 2006
From: kkarabuk at thoughtworks.com (Kurman Karabukaev)
Date: Wed, 22 Nov 2006 14:12:45 -0800
Subject: [mocha-developer] .class call to the mock object (or any existing
	methods)
Message-ID: <OF1D5DDBF6.0F45EE5D-ON8625722E.00790BDB-8825722E.0079FE86@thoughtworks.com>

Hi
I run into problem trying to set expectations for the mockobject.class 
method, I had to undefine a method before I could set some expectation. Is 
there any better way of doing it? 

object = mock()
....
klass = class <<object; self; end 
klass.send(:undef_method, "class")  # I had to do this because Mocha 
utilizes "method_missing(symbol, *arguments, &block) " method.
object.expects(:class).returns(SomeClass) 
...


And thanks for such a nice library.
------------------------------
Kurman Karabukaev
Application Developer
ThoughtWorks Inc.
(312) 282 0231

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mocha-developer/attachments/20061122/fa8a9d14/attachment.html 

From jamesmead44 at gmail.com  Thu Nov 23 05:17:31 2006
From: jamesmead44 at gmail.com (James Mead)
Date: Thu, 23 Nov 2006 10:17:31 +0000
Subject: [mocha-developer] stubbing in development environment
In-Reply-To: <ffc81db0611221038r239e4ccgb8c7433e3e1eecfc@mail.gmail.com>
References: <ffc81db0611211045q2e0079cbqbaf034e49d2c3dea@mail.gmail.com>
	<1db558f00611220207h4fa3e0am8017a00d2872965f@mail.gmail.com>
	<ffc81db0611220238u620e50d2t6e0922990990ca68@mail.gmail.com>
	<1db558f00611220652i4017a199ne526f4d917f86aa1@mail.gmail.com>
	<ffc81db0611221038r239e4ccgb8c7433e3e1eecfc@mail.gmail.com>
Message-ID: <1db558f00611230217s18e213a1n1c74d6524978e534@mail.gmail.com>

On 22/11/06, Jason Watkins <jason at jasonwatkins.net> wrote:
>
> > I think the objections are more practical than philosophical. If you are
> new
>
> Right. I wasn't interested in this particular debate.


I'm sorry I appear to have touched a nerve. I was merely trying to pass on
advice that I have found useful in my own work.

> Some of these hooks are not considered parts of the published API and so
> are
> > subject to change.
>
> Right. I've gotten this far on my own. My bringing it up is to

suggest that perhaps it should be part of the API.


As I tried to explain, I think one of the main problems in doing this is
finding somewhere to call the hooks I mentioned in my last email. If you
take the view that you only want to use stubs and have no requirement for
verifying expectations, you still need to decide when to create the
$stubbaglobal variable and when to revert the stubbed objects/classes
to their
original state. Do you have some constructive ideas on this front?

If you feel "you shouldn't do that, so I'm not going to help you do
> it", then another justification would be so that mocha isn't wired so
> directly to Test::Unit.


I think you're being harsh when you say that "I'm not going to help you"
when I gave you the four point explanation below. You should also note that
the HEAD version of Mocha already has a Standalone module which is not wired
directly to Test::Unit, to allow simple integration with other testing
frameworks.

There is nothing to stop you using Mocha in your development environment,
but there are a few issues you should think about...

    1) No convenience methods for creating mocks or stubs - you would have
to directly instantiate them using something like Mocha::Mock.new

    2) $stubba global variable is not defined - you would have to do
something like $stubba = Mocha::Central.new

    3) No auto-verification of expectations - you would have to explicitly
call the verify method on traditional mock/stub objects and
$stubba.verify_all to verify expectations on real objects

    4) Probably most importantly, no rolling back of stubbing - you would
have to explicitly rollback by calling $stubba.unstub_all

Another example would be exploratory programing.

It looks like I'll just write my own.


 Good luck.

-- 
James.
http://blog.floehopper.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mocha-developer/attachments/20061123/6ee881b1/attachment.html 

From jamesmead44 at gmail.com  Thu Nov 23 05:30:27 2006
From: jamesmead44 at gmail.com (James Mead)
Date: Thu, 23 Nov 2006 10:30:27 +0000
Subject: [mocha-developer] .class call to the mock object (or any
	existing methods)
In-Reply-To: <OF1D5DDBF6.0F45EE5D-ON8625722E.00790BDB-8825722E.0079FE86@thoughtworks.com>
References: <OF1D5DDBF6.0F45EE5D-ON8625722E.00790BDB-8825722E.0079FE86@thoughtworks.com>
Message-ID: <1db558f00611230230wfa9b2d1vb852a9464266a8bd@mail.gmail.com>

On 22/11/06, Kurman Karabukaev <kkarabuk at thoughtworks.com> wrote:

> I run into problem trying to set expectations for the mockobject.classmethod, I had to undefine a method before I could set some expectation. Is
> there any better way of doing it?
>
> object = mock()
> ....
> klass = class <<object; self; end
> klass.send(:undef_method, "class")  # I had to do this because Mocha
> utilizes "method_missing(symbol, *arguments, &block) " method.
> object.expects(:class).returns(SomeClass)
> ...


This is a known problem. There isn't currently a better way. I hope to
release a new version shortly which will allow you to mock methods defined
in Object, etc.

And thanks for such a nice library.


I'm glad you like it.

-- 
James.
http://blog.floehopper.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mocha-developer/attachments/20061123/7986fd91/attachment.html 

From jamie.macey at gmail.com  Thu Nov 23 20:21:00 2006
From: jamie.macey at gmail.com (Jamie Macey)
Date: Thu, 23 Nov 2006 17:21:00 -0800
Subject: [mocha-developer] .class call to the mock object (or any
	existing methods)
In-Reply-To: <OF1D5DDBF6.0F45EE5D-ON8625722E.00790BDB-8825722E.0079FE86@thoughtworks.com>
References: <OF1D5DDBF6.0F45EE5D-ON8625722E.00790BDB-8825722E.0079FE86@thoughtworks.com>
Message-ID: <beca44380611231721p1cf7f9bbw7490b36b5571de4e@mail.gmail.com>

On 11/22/06, Kurman Karabukaev <kkarabuk at thoughtworks.com> wrote:
>
> Hi
> I run into problem trying to set expectations for the mockobject.class
> method, I had to undefine a method before I could set some expectation. Is
> there any better way of doing it?
>
> object = mock()
> ....
> klass = class <<object; self; end
> klass.send(:undef_method, "class")  # I had to do this because Mocha
> utilizes "method_missing(symbol, *arguments, &block) " method.
> object.expects(:class).returns(SomeClass)
> ...

I presume you're then doing something along the lines of:

  if object.class == SomeClass

Is there some way you could refactor it to use kind_of? or
instance_of? instead of asking directly for the class?  I would assume
those methods would be less of a pain to mock than class.

- Jamie

From francois.beausoleil at gmail.com  Tue Nov 28 10:02:18 2006
From: francois.beausoleil at gmail.com (Francois Beausoleil)
Date: Tue, 28 Nov 2006 10:02:18 -0500
Subject: [mocha-developer] Partial matches in expectations
Message-ID: <41d5fadf0611280702l66665c55i2f6b9db49b953bca@mail.gmail.com>

Hi !

I would like to ascertain the following in a test case:

@template.expects(:content_tag).with(:fieldset, :__any_arguments__i_dont_care)

Is it possible to do so ?  If so how ?  If not, is it something the
community wants ?  Is it useful ?

Thanks !
-- 
Fran?ois Beausoleil
http://blog.teksol.info/
http://piston.rubyforge.org/

From jamesmead44 at gmail.com  Tue Nov 28 10:24:34 2006
From: jamesmead44 at gmail.com (James Mead)
Date: Tue, 28 Nov 2006 15:24:34 +0000
Subject: [mocha-developer] Partial matches in expectations
In-Reply-To: <41d5fadf0611280702l66665c55i2f6b9db49b953bca@mail.gmail.com>
References: <41d5fadf0611280702l66665c55i2f6b9db49b953bca@mail.gmail.com>
Message-ID: <1db558f00611280724n236b1235l6dcfbdab649cc36f@mail.gmail.com>

On 28/11/06, Francois Beausoleil <francois.beausoleil at gmail.com> wrote:
>
> I would like to ascertain the following in a test case:
>
> @template.expects(:content_tag).with(:fieldset,
> :__any_arguments__i_dont_care)
>
> Is it possible to do so ?  If so how ?


It should be possible to do this as follows...

@template.expects(:content_tag).with { |*params| params.first == :fieldset }

The with() block should return true or false depending on whether the
expectation should match.

-- 
James.
http://blog.floehopper.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mocha-developer/attachments/20061128/890622e0/attachment.html 

From francois.beausoleil at gmail.com  Tue Nov 28 10:54:33 2006
From: francois.beausoleil at gmail.com (Francois Beausoleil)
Date: Tue, 28 Nov 2006 10:54:33 -0500
Subject: [mocha-developer] Partial matches in expectations
In-Reply-To: <1db558f00611280724n236b1235l6dcfbdab649cc36f@mail.gmail.com>
References: <41d5fadf0611280702l66665c55i2f6b9db49b953bca@mail.gmail.com>
	<1db558f00611280724n236b1235l6dcfbdab649cc36f@mail.gmail.com>
Message-ID: <41d5fadf0611280754x58a4459et1a7896f943a78f75@mail.gmail.com>

Hello James !

2006/11/28, James Mead <jamesmead44 at gmail.com>:
> @template.expects(:content_tag).with { |*params| params.first == :fieldset }

Thanks.  I remember reading that somewhere before.  You should have
told me to read the friggin' manual :)

Thanks, works great !
-- 
Fran?ois Beausoleil
http://blog.teksol.info/
http://piston.rubyforge.org/