Module testing inside test_harness: verbose output ?

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

Monks,

When running a 'make test' (obtained from module-starter) all module output is suppressed. The test in t/ are called using test_harness() which uses TEST_VERBOSE. Setting TEST_VERBOSE to other values than 0 enables print DEBUG statements from the .t files, but not from the modules themselves. Commenting NOECHO does not do it either. What is the regular approach when trying to debug a module in this context ? Or, is it that modules are usually not debugged when running 'make test' ? I could make a test program to debug the modules out of 'make test' so module console output is allowed, although I kind of expected that this could be done while running 'make test'.

Thanks for any suggestions/ideas/comments.

Best wishes to all for 2010!

Comment on Module testing inside test_harness: verbose output ?

Replies are listed 'Best First'.
Re: Module testing inside test_harness: verbose output ? by MidLifeXis (Monsignor) on Dec 31, 2009 at 15:03 UTC
Look at what is generated by Test::Inline. It creates a variable for STDOUT and STDERR, and captures all output there. I have used this approach to check for error messages, proper output, menus, etc. Just looked at this module again (it has been a while since I have refreshed my copy), and I am not certain that it still does this the same way as was done in 0.15 (wow - time to refresh). See specifically $_STDOUT_ and $_STDERR_ variables. --MidLifeXis	[reply]
Re: Module testing inside test_harness: verbose output ? by stevieb (Canon) on Dec 31, 2009 at 14:44 UTC
When I'm writing tests and hit a snag within a module sub, I just use perl to run the test, which will allow you see the print statements within the module: `acct-dev: ISP-RADIUS % perl t/03-date.t ok 1 - use ISP::RADIUS; ok 2 - ISP::RADIUS->can('date') ok 3 - date() dies if the get param is incorrect ...printing from module ok 4 - calling date() with no params, return isa DateTime ...printing from module ok 5 - called with get=>month works out ok ...printing from module ok 6 - If the timezone isn't set correctly, we die` [download] Hope this is what you were after Steve	[reply] [d/l]