|
»
»
« Return to Thread: Extra option for ClassImposterizer
Re: Extra option for ClassImposterizer
by Steve Freeman-2
::
Rate this Message:
Understood. We're always in that situation. But, if you have some
control over the mocked class, I suggest adding an interface to it
that represents the relationship between it and the object under test.
Then the target object only deals with the interface and you can mock
it directly. You get to avoid dealing with the internals of the mocked
class.
Would that work?
S.
On 23 Apr 2009, at 15:23, Ignat Zapolsky wrote:
> unfortunately it is not always possible to have great code from the
> beginning (assume a legacy code base that was written by programmers
> of different skills), thus we are forced to use ClassImposterizer.
> And my idea was only to isolate one method of a class under test,
> but not to call a method of an external library for which I'll
> definitely introduce an interface & proxy object (as was described
> in your post).
>
> Steve Freeman wrote:
>> Personally, my first reaction is that this is missing the point.
>>
>> What /we/ are trying to achieve is a clean distinction between an
>> object and its collaborators, so cutting a slice through another
>> object where we use some bits but not others doesn't help with
>> that. The only motivation for us to do this would be because we're
>> working with a third-party library we can't change. In which case,
>> we'd introduce an interface to collaborate with and a thin veneer
>> to implement that interface in terms of the external class.
>> Otherwise, we'd break up the external object, or at least have it
>> implement an interface that describes the relationship we need.
>>
Steve Freeman
Winner of the Agile Alliance Gordon Pask award 2006
http://www.m3p.co.uk
M3P Limited.
Registered office. 2 Church Street, Burnham, Bucks, SL1 7HZ.
Company registered in England & Wales. Number 03689627
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
control over the mocked class, I suggest adding an interface to it
that represents the relationship between it and the object under test.
Then the target object only deals with the interface and you can mock
it directly. You get to avoid dealing with the internals of the mocked
class.
Would that work?
S.
On 23 Apr 2009, at 15:23, Ignat Zapolsky wrote:
> unfortunately it is not always possible to have great code from the
> beginning (assume a legacy code base that was written by programmers
> of different skills), thus we are forced to use ClassImposterizer.
> And my idea was only to isolate one method of a class under test,
> but not to call a method of an external library for which I'll
> definitely introduce an interface & proxy object (as was described
> in your post).
>
> Steve Freeman wrote:
>> Personally, my first reaction is that this is missing the point.
>>
>> What /we/ are trying to achieve is a clean distinction between an
>> object and its collaborators, so cutting a slice through another
>> object where we use some bits but not others doesn't help with
>> that. The only motivation for us to do this would be because we're
>> working with a third-party library we can't change. In which case,
>> we'd introduce an interface to collaborate with and a thin veneer
>> to implement that interface in terms of the external class.
>> Otherwise, we'd break up the external object, or at least have it
>> implement an interface that describes the relationship we need.
>>
Steve Freeman
Winner of the Agile Alliance Gordon Pask award 2006
http://www.m3p.co.uk
M3P Limited.
Registered office. 2 Church Street, Burnham, Bucks, SL1 7HZ.
Company registered in England & Wales. Number 03689627
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
« Return to Thread: Extra option for ClassImposterizer
| Free embeddable forum powered by Nabble | Forum Help |
