Mock Objects
Locked
 
|
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 |
|
|
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 <[hidden email]> 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 > > |
|
|
In reply to this post by Torsten Bergmann
I see nice....
I really like the idea to teach something useful to these objects :) On 27 juin 06, at 18:54, Torsten Bergmann 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 > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |