[Mpls-pm] Code I whiteboarded tonight

[Troy E. Hove Tausend]

On Wednesday 14 September 2005 11:17 pm, Joshua ben Jore wrote:

>
> If you're going to use isa()/can() and you think your code might be
> used by someone who writes tests, you should be using them as methods
> anytime you have an object. People using Test::MockObject rely on the
> method form of isa() being overrideable.
>
> I haven't used T::MO myself but I think I'm accurately relaying what
> the Test::MockObject users are typically complaining about.
>
> Josh
> _______________________________________________
> Mpls-pm mailing list
> Mpls-pm at pm.org
> http://mail.pm.org/mailman/listinfo/mpls-pm

  I have used Test::MockObject.  I would say that it was not intended to 
replace "real" objects in the tests for those classes/objects which happens 
to be the only place that my code gets picky about pedigree.  It is useful 
for when you are testing something else that you might be throwing your 
objects at and need a stand-in/stunt double because the "real" object does 
undesireable things.

  It appears also that there is now UNIVERSAL::isa and UNVERSAL::can modules 
used by Test::MockObject to "fix" the functions so they will behave using the 
classes methods when appropriate.  They are very recent (copyright 2005).

  I see chromatic has now also added Test::MockObject::Extends so you can 
selectively mock methods of an existing class/object.  I ended up writing a 
module that does basically the same thing, but on a much more subtle level so 
that even stack traces don't see the subterfuge and the mocking can occur 
dynamically during execution, plus it works against plain old subroutines as 
well.  I'll look into submitting a patch, although I think the goals are 
different enough that my fancy pants stuff doesn't make sense as a subset of 
Test::MockObject.

-- 
Troy E. Hove Tausend
ttausend at hotmail.com
ttausend at gmail.com
ttausend at mn.rr.com