|Perl: the Markov chain saw|
[Solved] Best method of call tracing, without writing code?by Hercynium (Hermit)
|on Oct 05, 2007 at 16:36 UTC||Need Help??|
Hercynium has asked for the
wisdom of the Perl Monks concerning the following question:
I thought this was too simplistic a question for SoPW, but the CB was pretty well engaged in an interesting discussion that I decided trying to interrupt further would be rude :)
I have an existing code-base, and I want to begin writing a test suite for one of the modules. I've decided that the best way to start would be to determine exactly what data is being passed into each subroutine and what is getting returned.
So, for example, I want to be able to specify that all method and subroutine calls in module Foo::Bar get logged, complete with a dump of the passed arguments and the returned data. This has to be done without modifying any existing code. (Adding a single 'use' at the top of the main script is acceptable, though)
I found Debug::Trace which looks like it will do the job, and the author looks like someone who knows his stuff (He also wrote the venerable Getopt::Long!) but I wonder if there is a better, more fitting solution to which the wisdom of the Monks can illuminate.
Update: Down the rabbit hole we go... I've now tried Debug::Trace, Devel::TraceCalls, and Devel::TraceMethods, and none worked... BUT I have an idea why.
The module that *uses* the module whose methods I want to trace is loaded dynamically, at run-time through a mechanism I created with an eval. In other words, the methods that call the methods I want to analyze are in a module that isn't used until run-time, and therefore the module containing the methods I want to analyze is not loaded until run-time. Ick...
It's a bit complicated to describe - the code is on CPAN as TL1ng. (please don't take this as a plug for my module... it's still young and fragile.)
Update 2: Eureka! Since I am testing, I already know which module will be loaded at run-time... so I can pre-load it and now Debug::Trace works!
Of course, it would still be nice to get some more feedback on other better/best/interesting debugging techniques of similar ilk!
Ikegami - Even though I figured it out before you posted, Thank you!