|
»
« Return to Thread: Extra option for ClassImposterizer
Re: Extra option for ClassImposterizer
by Ignat Zapolsky
::
Rate this Message:
Ehm, this looks like I lack of explanation skills.
For example, I would like to refactor a big fat class with dozens of
public / protected / default access methods which could call other
public / protected / default methods and this class does not have
associated Unit Test (well, it was never written thus class became big &
fat).
And I would like to create a test fixture which will deal with one
public / protected / default method at a time but not with whole stack
of interleaved method invocations.
I hope this description is slightly better than few before.
Steve Freeman wrote:
> 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
>
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
For example, I would like to refactor a big fat class with dozens of
public / protected / default access methods which could call other
public / protected / default methods and this class does not have
associated Unit Test (well, it was never written thus class became big &
fat).
And I would like to create a test fixture which will deal with one
public / protected / default method at a time but not with whole stack
of interleaved method invocations.
I hope this description is slightly better than few before.
Steve Freeman wrote:
> 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
>
>
---------------------------------------------------------------------
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 |
