Hi Josh, > Not true. If you real perldebguts you'll see that the debugger can be > scripted or you could write your own debugger.
right and right but Devel::Ebug is simply much cleaner and I'd rather not mock a debugger when I can use a real one. Hi Adrian, >> The first problem I have is capturing the module output >>... >You might want to look at Test::Output for this. Doesn't work either. >> I will also have a bunch of tests that need to be run under the >> debugger. >Why? (he asks curiously :-) The module is called Debug::Mixin (though it might be called something else when released). It's a module to help applications and modules be more debuggable. it allows you to write a set of files with breakpoints. when debugging, you choose which set you want. This could certainly be achieved through the debugger directly but this also works without the debugger to achieve logging of debug information etc... Think of this module as a smart TRACE where TRACE is a bunch of subs. one of those subs may decide it's time for you to have a look at the current code in a debugger (if any running) >Personally I wouldn't get /too/ hung up about 100% test coverage - it >can be taken too seriously. See Brian Marick's "How to Misuse Code >Coverage" <http://www.testing.com/writings/coverage.pdf> for example. Thanks for the article link. I've seen bad test code with 100% coverage but I've never seen good test code with bad coverage. Also, I'd rather not have 98.7% coverage. It's nagging me and I'd rather spend five extra minutes to get 100%. >> A propos coverage, I have a module (Text:::Vip) that fiddles quite >> a lot with >> member subs, adding them dynamicaly. The more tests I added, the least >> coverage I got! >Not personally :-) Never having delved into the guts to D::C my guess >would be that you're generating new subs and only every testing part >of the new sub - so you're creating more uncovered code than not... >Without seeing the code it's hard to tell :) Want to see the code? Text::Vip on CPAN. Cheers, Nadim.
