Re: Measuring Complexity (was Re: Perl::Metrics::Simple 0.30)
Matisse Enzer wrote: On Dec 15, 2006, at 10:13 PM, Chris Dolan wrote: OK, I see. Perhaps I was distracted from your main point by mention of cyclomatic complexity, which has a rather specific definition. Mea culpa. In the next release I will change the documentation for Perl::Metrics::Simple to make clear how exactly the complexity score is calculated, and that it is only an approximation of true cyclomatic complexity. Meanwhile, I am open to making the measurement more useful. For example, should if ($a eq $b) or if ( $a == $b ) be counted as more complex than: if ( $a ) ? I don't think so. The latter is simply an implicit version of the former. It means something like: if ( $a == $true_value || $a eq $true_value ) Another way of looking at it is that comparison operators are no different than any other expressions. if ( func() ) if ( --$a ) The expressions themselves do not represent branches. They just produce values that may be used as the basis for a branch. Randy.
Re: testing module loading output and testing under the debugger
On 12/17/06, Nadim Khemir <[EMAIL PROTECTED]> wrote: I will also have a bunch of tests that need to be run under the debugger. I will use Devel::ebug as it is the only way to control the debugger. There are tests in the ebug distribution that I might be able to copy but I would also like to try this in the "standard" perl debugger. has anyone experimented with something similar? Not true. If you real perldebguts you'll see that the debugger can be scripted or you could write your own debugger. They can even be ultra-simple things that are just a few lines long. I wrote a debugger the other day and it was somewhere around five lines long. All it did was report the depth of the call stack but that's all I wanted. Josh
Re: testing module loading output and testing under the debugger
On 17 Dec 2006, at 20:46, Nadim Khemir wrote:
[snip]
The first problem I have is capturing the module output when it is
loaded.
I tried:
[snip]
You might want to look at Test::Output for this.
[snip]
I will also have a bunch of tests that need to be run under the
debugger.
[snip]
Why? (he asks curiously :-)
[snip]
To get a 100% coverage I had to run this test:
dies_ok
{
Bum::Config::new () ;
} "invalid constructor" ;
How do you guys test this?
[snip]
That's a reasonably thing to do if that's the behaviour you're
interested in. If I was throwing some kind of structured exception I
might use throws_ok and test for it explicitly - but dies_ok is fine
if any-old-exception is what you want to happen.
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" for example.
[snip]
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!
[snip]
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 :)
Cheers,
Adrian
testing module loading output and testing under the debugger
Hi,
I'm writing a module to help debug application. I have used it in PBS for a
while and I wanted to rewrite it "right" with tests and all.
= 1 =
The first problem I have is capturing the module output when it is loaded.
I tried:
my $capture ;
BEGIN
{
$capture = IO::Capture::Stdout->new();
$capture->start();
}
{
local $Plan = {'load without debugger, Debug::Mixin banner NOT shown' => 1} ;
$capture->stop();
my @all_lines = $capture->read;
is("@all_lines", "expected", "message") ;
}
without any success.
= 2 =
I will also have a bunch of tests that need to be run under the debugger. I
will use Devel::ebug as it is the only way to control the debugger. There are
tests in the ebug distribution that I might be able to copy but I would also
like to try this in the "standard" perl debugger.
has anyone experimented with something similar?
= 3 =
To get a 100% coverage I had to run this test:
dies_ok
{
Bum::Config::new () ;
} "invalid constructor" ;
How do you guys test this?
= 4 =
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!
Has anyone seen this before?
Cheers, Nadim.
