Thanks for the insight, Torsten.

I have already begun to run into problems with #initialize in mocks,
so I'll take Teachable for a spin.  I also prefer the more intention
revealing nature of Teachable's #whenSend:return, over my
implementation's #on:do.

I find I am using mocks as a type of scaffolding which helps me
explore the behaviors I'll need to implement in the classes I'm
mocking.  Once I acually create the real class (or a mock class of the
real class), I'll likely replace my on-the-fly mocks with them.

Again, I only started using mocks a few weeks ago, so I appreciate your insight.

Chad

On 6/27/06, Torsten Bergmann <astares at gmx.de> wrote:
> Hi Stef,
>
> the MockObject class from Chad is just a simplified version of the Teachable
> package I wrote about before. Teachable is able to handle more cases.
>
> see http://astares.blogspot.com/2005/04/teaching-behavior.html
>
> Since Teachable does not implement #initialize (like it is the case in Chads MockObject class) you
> are also able to teach the mock how to behave when an initialize method is sent
> to it.
>
> Just download the package using SM and have a look at the provided test case.
> Teachable is also more intention revealing. Instead of just working
> with blocks you can write Chads example with Teachable as:
>
> cart := Cart new.
> item := Teachable new.
> item whenSend: #total return: 2.99.
> cart add: item
> ...
>
>
> But as I warned in the previous email: creating dynamic mock objects
> (using either Chads code or the Teachable package) is sometimes dangerous.
>
> Think of testing persistence layer code in an application. If you want to get
> the tests running without having an actual database connection you can mock it.
> You can either either teach an object dynamically how to behave like the real
> DB connection class or implement the mock also as a class with the same signature.
>
> In such a case I would prefer to implement a real mock class since it can become
> a nightmare to debug the code with the #doesNotUnderstand: trick (especially when it
> uses blocks). It is also hard if you refactor the mocked code - this always means
> to refactor the mock object in a similar way.
>
> The more behavior/logic to mock the better it is to implement a special mock class
> with a similar interface. We just need better tools.
>
> Smalltalk with it's dynamic nature is very powerful - especially for testing. Think of
> a general mock framework where mocks can dynamically created from the "mocked object"
> or where one can use SUnit to even test the mock:
>
>        "self assert: (aMockObject behavesLike: mockedObject)".
>
>
> Bye
> Torsten
>
> --
>
>
> "Feel free" – 10 GB Mailbox, 100 FreeSMS/Monat ...
> Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
>
>