It sounds like you are pursuing a rather intriguing testing scenario with regard to a complex legacy application. I also have experienced that complex and sometimes interlocking inheritance-paths can create situations that are extremely difficult to test with any confidence that the testing scenario that you’re trying to set up actually matches the reality of the application. Never really found a good way to approach it, and I didn’t think of this. I’d love to read a Meditation about what you are doing and/or about the issues that you’re dealing with now, someday soon ...
| [reply] |
I would suggest creating an empty subclass then:
package Test::It;
our @ISA = qw(Package::Under::Test Utility::Subs);
1;
# ... later, in another file
my $under_test = Test::It->new(...);
This way any method is first searched in the Package::Under::Test's hierarchy and only then in Utility::Subs. | [reply] [d/l] |
For my (possibly unrelated ...?) purposes, it would need to be being able to build a more isolated test case situation, especially for adding instrumentation to an existing, complex but poorly-designed class structure ... without significantly changing the crufty old code, if at all.
I have noticed that heavily class-based code over time can wind up having a lot of “side effects,” for lack of a more proper term, which can make it difficult to deduce exactly which code-path is being taken. And, when you don’t yet really know whether any particular one of those paths are or are not reliable, that’s a big deal, at least in my situation. (I mostly deal with legacy code ... eight years old or more ... stuff that stinks but drives businesses.) I don’t want to “hijack” this particular thread into that direction, though, but I’m interested.
| [reply] |