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.
In reply to invoking module functions from a test script by chexmix
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |