invoking module functions from a test script

chexmix has asked for the wisdom of the Perl Monks concerning the following question:

Greetings, Monks. And Happy Thanksgiving!

I'm running into a problem testing a module (call it My::NEW::Module) I wrote for work.

My::NEW::Module and the test script 'use' another module I wrote years ago, let's call that one My::OLD::Module -- which for better or worse* was written to simplify our DBI-driven interactions with databases.

What I am trying to test is the new module's ability to issue a query to a database and get results back.

So in the test script I create (successfully) a database handle (care of My::OLD::Module) and then call one of the functions (get_unpublished) in My::NEW::Module, using the database handle and a couple of other numeric values as parameters.

This test was crapping out because (the output said) the function create_query could not be found:

Can't locate object method "create_query" via package "My::NEW::Module" at ../lib/My/NEW/Module.pm line 46.

This message makes sense on one level because create_query is a function in My::OLD::Module, intended to be called by database handles created by My::OLD::Module -- it is not a function of the NEW module. But ... why was the function being called against the wrong object/module?

After tearing out some hair, I decided to try stepping through with the debugger to see if I could spot the problem. I think I did. At one point in the output I saw this:

"My::NEW::Module::get_unpublished('My::NEW::Module', 'My::OLD::Module::Connect=HASH(0x45dcd98)', 10, 250) called at module_test.t line 44"

So a function that takes (and has been called with) three parameters is actually (somehow) winding up with four instead.

And when the module function loads three variables from the @_ array, it is getting My::NEW::Module as the first value, which should be the database handle. This causes problems when the subroutine, which assumes that that variable represents a My::OLD::Module-style database handle, tries to call one of the handle's own methods ... this basically explains the error I was seeing from the test script. I could follow all this happening in the debugger output.

I am particularly confused because I have used My::NEW::Module from scripts I am writing and in that context, it has worked fine (yeah, I'm writing tests retroactively, which I realize is bad).

I tried explicitly changing the My::NEW::Module code so that it shifts the My::New::Module object off the @_ array explicitly, but when I do that the scripts that use the module error out.

So it appears this problem only exists in the testing environment. I admit I am completely mystified.

Does what I have described suggest ... anything? I know I haven't really posted code, and I apologize in advance if I have described this poorly.**

Anyhoo, thanks,

Glenn

* I'm painfully aware that in this case it's at least 99% 'worse' - DBI isn't hard to use. I only mention this b/c I have posted about this module on Perlmonks before and gotten lots of "why did you bother doing that?" It's a fair question.

** I fear I might be encountering the inescapable fact that the way we use Perl in my department is non-standard to say the least. Unfortunately, I have not had the time to fix the endemic problems. Perl programming is only part of my job. It has been very frustrating.

Comment on invoking module functions from a test script Select or Download Code

Replies are listed 'Best First'.
Re: invoking module functions from a test script by haukex (Archbishop) on Nov 27, 2019 at 18:34 UTC
`Can't locate object method "create_query" via package "My::NEW::Module" at ../lib/My/NEW/Module.pm line 46.` `My::NEW::Module::get_unpublished('My::NEW::Module', 'My::OLD::Module::Connect=HASH(0x45dcd98)', 10, 250) called at module_test.t line 44` So a function that takes (and has been called with) three parameters is actually (somehow) winding up with four instead. Sounds like you accidentally wrote `My::NEW::Module->get_unpublished(...)` when you meant `My::NEW::Module::get_unpublished(...)`? Otherwise, try reducing the code down to the bare minimum needed to reproduce the problem, so you can post it here - see Short, Self-Contained, Correct Example.	[reply] [d/l] [select]
Re^2: invoking module functions from a test script by chexmix (Hermit) on Nov 27, 2019 at 18:37 UTC
Well, um. Right you are! Thanks and sorry for ... well, for too many words ;) G	[reply]
Re^3: invoking module functions from a test script by bliako (Monsignor) on Nov 27, 2019 at 22:24 UTC
if rubber ducks had ears ... (bottom line is: in calling an object's method, $object->method(1,2,3), 1st received param is always the object ref, followed by all other params you called that method with, the 1,2,3. That's not the same when calling a class method "statically", e.g. class::method(1,2,3) -- you get 1,2,3 as params, no object ref this time as there is none.)	[reply]


Welcome to the Monastery
	PerlMonks