Jonathan Rockway wrote:
> While I agree with David, this argument is almost completely pointless.
> Nobody reads the raw TAP output!
are you serious? listen to what they people here are saying - we _all_
read the raw TAP output, all the time, and not because we're TAP
developers interested in th
> However, most perl tests don't care about TAP, they use Test::More and
> Test::Harness and happen to exchange data via TAP. If Test::More and
> Test::Harness decied to use "YAP" (YAML Anything Protocol? :), then most
> applications would probably never notice.
most _perl_ applications would ne
Ovid wrote:
> - Original Message From: Jonathan Rockway <[EMAIL PROTECTED]>
>
>> What else is TAP targeted to? C / C++ / Java?
>
>
> PHP tests often use TAP (don't know the name)
almost all of the php test frameworks now offer TAP support - see
http://search.cpan.org/dist/Test-Harn
Michael G Schwern wrote:
> On 2/9/06, Geoffrey Young <[EMAIL PROTECTED]> wrote:
>
>> > This works:
>>
>> yes, excellent randy. thanks for that. it still seems a little
>> hackish but
>> that's ok - hackish works for me if it means I can do w
Geoffrey Young wrote:
> I've mentioned the idea of making it simple to use
> plan() and Test::More functions before
blarg... insert "separately" ^ here. all the rest is pretty simple
already :)
--Geoff
sorry for dropping in on this late, but it was a holiday weekend :)
> * How can I help?
>
> Provide use cases, what would you want to do with Test::Harness if you
> could? What are you doing with Straps? What features do other
> testing systems (JUnit, for example) have that you'd like to see i
hi all :)
so, as a standard practice, I start with
use_ok($class);
as the first test in each file, the idea being that if the class doesn't
compile I shouldn't care about the results of the rest of the test - I
know immediately that subsequent failures are because I introduced a
typo or someth
Nik Clayton wrote:
> Geoffrey Young wrote:
>
>>> Since you're using C++, you can probably use libtap
>>> (http://www.onlamp.com/pub/a/onlamp/2006/01/19/libtap.html and
>>> http://jc.ngo.org.uk/trac-bin/trac.cgi/wiki/LibTap) for writing the
>>> te
> Since you're using C++, you can probably use libtap
> (http://www.onlamp.com/pub/a/onlamp/2006/01/19/libtap.html and
> http://jc.ngo.org.uk/trac-bin/trac.cgi/wiki/LibTap) for writing the tests and
> then you could use a Perl harnes to collect those results.
just out of curiosity, has anyone got
Pete Krawczyk wrote:
> Subject: skip_all with Test::More?
> From: Tels <[EMAIL PROTECTED]>
> Date: Wed, 31 May 2006 17:53:46 +0200
>
> }
> }use Test::More;
> }
> }plan tests => 123;
> }
> }skip_all( 'reason' ) if ...;
> }
> }# tes
Adam Kennedy wrote:
>
>>> Schwern made one small change in the STDERR format, and the recursive
>>> cascade of failing test-testing modules hit something like 3000 CPAN
>>> distributions.
>>
>>
>> While I agree that this caused problems, those modules were relying on a
>> format that was not spe
chromatic wrote:
> On Monday 17 April 2006 18:50, Ovid wrote:
>
>
>>The only problem I see with that is the occasional buffering errors I
>>see on my Mac where the STDERR and STDOUT don't line up.
>
>
> Agreed. Is it too late to send everything to STDOUT where it belongs?
just for everyone'
Andy Lester wrote:
>
> I'm adding a section to Test::Harness::TAP on non-Perl TAP.
>
> http://svn.perl.org/modules/Test-Harness/trunk/lib/Test/Harness/TAP.pod
>
> If you know of one, please send me some text to add.
all the big PHP players now produce TAP
o phpt (outputs TAP by default as
>
> A-T requires me to do things differently, and it's that difference that
> introduces the lack of flexibility.
I had a bunch of foo written that I removed, mainly because this is the real
issue, for you I guess - the idea that different is somehow bad or
inflexible, that anyone who creates so
we should keep this on list :)
Adam Kennedy wrote:
>
>
> Geoffrey Young wrote:
>
>>
>> Adam Kennedy wrote:
>>
>>> I'd also add a small warning in that Apache::Test does seem to want to
>>> dominate the entire test suite (run everything
Adam Kennedy wrote:
> I'd also add a small warning in that Apache::Test does seem to want to
> dominate the entire test suite (run everything from TEST) and so may not
> be as suitable in cases where you have 50-500 test scripts already, and
> you just want a few to work with Apache::Test and a n
> Apache::Test looks like it might be the way to go. But it doesn't seem
> to play very nicely with Test::More,
that's not really true. yes, Apache-Test was based on Test.pm (for various
reasons I won't get into here) but I added Test::More support and use it all
the time. grep for stuff lik
David Cantrell wrote:
> Geoffrey Young wrote:
>
>>> "Only the simplest of designs benefits from pre-coded tests, unless
>>> you have
>>> unlimited developer time."
>>
>> needless to say I just don't believe this.
>
>
>
hi all :)
for those interested in both php and perl, it seems that php's native .phpt
testing feature will soon produce TAP compliant output - see greg beaver's
comments here
http://shiflett.org/archive/218#comments
so, TAP is slowly dominating the world... but we all knew that already :)
wha
>>> I've long intended to take t/test.pl from the Perl core distribution
>>> and wrap
>>> up at least its runperl() in a Test:: module. Perhaps that would
>>> work for
>>> you?
>>
>>
>> compile_ok() ?
>>
>> --Geoff
>>
>
> It is unclear from Geoff's message above whether he is asserting that
>
chromatic wrote:
> On Wednesday 15 March 2006 12:25, Jeffrey Thalhammer wrote:
>
>
>>I'm sure I could clean this up by opening a pipe
>>instead of using backticks and output redirection.
>>But even that doesn't smell very good. I've looked
>>around on CPAN, but I have not yet found a Test::
>>
>> One of the problems is going to be numbering, surely?
but it shouldn't need to be, right? I mean, TAP is merely a protocol and
there shouldn't be a requirement that the bookkeeping happen in the same
process as the TAP emitting process I wouldn't think. in fact, if someone
were implementing
>> so, thoughts or ideas? am I making any sense?
>
>
> Yes, you are.
*whew*
:)
> I think that the subprocess can load Test::More and
> friends like this:
>
> use Test::More no_plan => 1;
> Test::More->builder->no_header(1);
cool, thanks.
>
> That will set No_Plan, Have_Plan, and No_Hea
hi all :)
there's a feature split I'm itching for in Test::Builder, etc - the
ability to call is() and have it emit TAP free from the confines of
plan(). not that I don't want to call plan() (or no_plan) but I want to
do that in a completely separate perl interpreter. for example, I want
to do s
> Nice work, Geoff
:)
>
> A few issues:
>
> 1)
>
> % make testcover
> Cannot run testcover action unless Devel::Cover is installed
>
> and after installing Devel::Cover it still gives the same error, since
> it's hardcoded in Makefile.PL. May be adding a check and suggesting to
> rebuild Mak
hi all :)
I just commited a patch to Apache-Test in svn that removes all the
additional work involved with getting Devel::Cover to work for server side
tests. now a simple 'make testcover' should be all you need to do to get
coverage results from code within handler() subroutines - no more adding
> No, not when I run the example out of the box - I had to move the
> PerlPassEnv directives to extra.conf.in and rebuild (this makes sense,
> though, as extra.conf is processed before modperl_extra.pl, while
> extra.last.conf is processed after - perhaps you fixed your local copy and
> haven't up
Hilary Holz wrote:
Okay - here's what I've figured out - D::C is not recording any coverage
info when I run a test in t/apache. D::C is recording coverage for all the
tests that are in the t/ directory - and the reports are in the realm of the
reasonable.
Have you had D::C collect coverage sta
> [snip - ah, helpful, now I understand how to use the testcover target]
:)
> Devel::Cover is reporting
> 100% statement coverage for a number of modules for which there are no tests
> as of yet (legacy modules I have yet to revisit)
I don't think that's unusual - D::C will aggregate all the r
> I'd really love to use Devel::Cover - I love the effect mastering the
> request/response Apache::Test framework has had on my code, and I really
> want to start using code coverage as part of my toolkit.
yah, this is a bit more complex than it probably ought to be, but I guess
that's by design.
Andy Lester wrote:
>> yeah, well, you could say that. last time I installed my washer I said
>> "looks pretty level to me, but I know where my level is if it makes a
>> racket"
>
>
> That's fine, but I'm still not shipping my washing machines without
> explicit instructions to level the dam
Andy Lester wrote:
>> Usually, Test::* modules are only used for the test phase.
>
>
> I really don't understand the idea of "only used for the test phase",
there is clearly a distinction between the code required for a given module
to compile and run in a production environment and the code r
They add some value to me (show that at least something works).
>>>
>>>Either they're valuable enough that you install their prerequisites or
>>>they're not.
>
>
> But how am I supposed to find this out? I dont even know whether the
> required modules are used for the tests only, without di
Michael G Schwern wrote:
> What I'm looking for is ideas about more things it could do that would
> be useful for most testing libraries. What scaffolding do module authors
> find themselves implementing?
if there were a better way to do this:
push @ISA, qw(Test::Harness::Straps);
$Test:
> (I deliberately
> did *not* list IO::Capture as a prerequisite in Makefile.PL because I
> didn't want to force users to install that module. I simply wanted them
> to use it during testing and then throw it away.
this is the start of the right attitude I think - when your testing
environment r
> http://www.justatheory.com/code/Test.Simple-0.10/tests/index.html?
> verbose=1
that's just awesome :)
nice work.
--Geoff
>>> This seems unfortunate for at least two reasons:
>>> 1) it ends up taking a really long time to run the tests. At some
>>> point, maybe long enough that nightly tests become prohibitive (even
>>> more so for continuous integration).
> We have a substantial Perl code base (as I've said sever
Ricardo SIGNES wrote:
> Yesterday, hide gave me some sweet example code to use
> HTTP::Server::Simple and Test::WWW::Mechanize to test Rubric's CGI bits.
> I've started working with them, and they make me happy.
>
> I've realized that the server, which is forked from the test script,
> doesn't h
Vsevolod (Simon) Ilyushchenko wrote:
> Hi,
>
> I'd like to suggest a module that I came up with to test CGI file
> uploading logic. I have not found anything else like it.
have you seen Apache-Test yet?
http://search.cpan.org/dist/Apache-Test/
I find it hard to understand modules like this a
David Wheeler wrote:
> On May 5, 2005, at 04:26 , Adrian Howard wrote:
>
Here's a weird idea: how about the option of AJAXing the test
harness results back to a receiving server somewhere that
understands TAP? Bingo: TAP testing of JS embedded in web pages in
its native ha
David Wheeler wrote:
> On Apr 7, 2005, at 5:55 PM, Michael G Schwern wrote:
>
>> If you have isDeeply() there's little point to the eq* salad.
>
>
> Hrm, fair enough. I'll comment them out, then...
well, a few thoughts here...
as someone familiar with T::M and not javascript, were I to try t
> test => { TESTS => join ' ', map { glob } qw( t/*/*.t t/*/*/*.t ) },
but slashes aren't portable, right? I don't think you can get rid of
File::Spec.
> Also, I agree that the use-Test-Plan-after-Test-More caveat is icky.
well, it's a caveat, not a requirement :)
the way it works now is t
hi all :)
following up on the discussion from a few months ago but renewed over the
weekend, here is Test::Plan. basically all it does is carry over the exact
syntax and helper functions we are already using in Apache-Test land to the
greater community.
I'm still working up additional tests, but
Michael G Schwern wrote:
> On Sat, Mar 12, 2005 at 11:41:08PM -0500, Geoffrey Young wrote:
>
>>well, this syntax doesn't exist in Test::More at the moment (though I
>>probably should get around to a patch like I promised) - it's only in
>>Apache-Test.
>
&
Mark Stosberg wrote:
> On 2005-03-13, Geoffrey Young <[EMAIL PROTECTED]> wrote:
>
>>nevertheless, what you are replying to was just a discussion about a feature
>>that doesn't exist in the standard Test::More toolkit but was brought up
>>because Apache-Test&#
Ian Langworth wrote:
> On 12.Mar.2005 11:41PM -0500, Geoffrey Young wrote:
>
>
>>nevertheless, what you are replying to was just a discussion
>>about a feature that doesn't exist in the standard Test::More
>>toolkit but was brought up because Apache-Test's
Ian Langworth wrote:
> On 30.Nov.2004 09:57AM -0600, Andy Lester wrote:
>
>
>> plan tests => 14, have( "Foo::Wango" ), moon_phase eq "waning", etc;
>
>
> Where does the reason fit into this syntax?
well, this syntax doesn't exist in Test::More at the moment (though I
probably should get ar
Joe Schaefer wrote:
> we should be able to communicate TAP via HTTP, SMTP, etc.).
TAP::Lite anyone?
/me ducks
;)
--Geoff
> Hm, that does seem valuable. Should all test modules report their
> versions by default, though?
well, my thought was that it was more important to list the source of the
comparison operators the user uses (like is() or eq_array()) than it was the
internal stuff that, say, interfaces with Test
> This is helpful for processing bug reports, so I don't have to make
> second trip back to the user to ask: "What version of CGI.pm where you
> using?".
yeah, I'll second this, at least so far as adding a version component to
Test::More goes (which is different than adding a TAP version, which
Ovid wrote:
> Is anyone even using THS?
/me raises his hand
> If anything, I
> suspect there are a tiny handful of people who have played with it, but
> haven't really used it since it's not as useful as it could be.
I got Apache-Test to run .php scripts in under 10 lines by subclassing
strap
> But for all Test::Builder based modules you can get the same intent with
> Test::Builder->reset.
yup, I used that for the port away from Test.pm - works like a charm :)
--Geoff
Michael G Schwern wrote:
> On Tue, Dec 21, 2004 at 04:53:18PM +0100, Tels wrote:
>
>>On Tuesday 21 December 2004 08:53, Michael G Schwern wrote:
>>
>>>I've gotten absolutely no response about Test::Legacy. Is anybody
>>>using it? Anybody tried migrating old Test.pm based tests with it?
>>
>>I
> Changing the subject slightly, is there any guidance on what people
> should write in the name/comment/label?
>
> I ask because several times I've been puzzled by a test failure
> where the message printed is ambiguous. Compare these two:
>
> not ok 42 - is red
>
> not ok 42 - sho
[Torsten Fortsch ]
added Apache::TestRunPHP and Apache::TestConfigPHP classes,
which provide a framework for server-side testing via PHP scripts
[Geoffrey Young]
fix problem with multiple all.t files where only the final
file was being run through the test harness. [Geoffrey Young]
Documented
> 0.49 Thu Oct 14 21:58:50 EDT 2004
excellent! thank you very much.
for the interested, Test::More support has now officially been added to
Apache-Test server-side tests, provided you have 0.49.
kudos all around.
--Geoff
ss runtime argument, which will start the server
in single-server mode (httpd -X in Apache 1.X or
httpd -D ONE_PROCESS in 2.X) [Geoffrey Young]
In open_cmd, sanitize PATH instead of clearing it [Gozer]
Allow / \ and \\ path delimiters in SKIP file [Markus Wichitill
<[EMAIL PROTECTED]>]
Add
erver mode (httpd -X in Apache 1.X or
httpd -D ONE_PROCESS in 2.X) [Geoffrey Young]
In open_cmd, sanitize PATH instead of clearing it [Gozer]
Allow / \ and \\ path delimiters in SKIP file [Markus Wichitill
<[EMAIL PROTECTED]>]
Added an apxs query cache for improved test performance [Gozer]
David Wheeler wrote:
> On Oct 5, 2004, at 12:43 PM, Geoffrey Young wrote:
>
>> no, it is required. but only cvs currently supports -one-process as an
>> option - earlier versions will explode.
>
>
> Okay. So I just added this to the testcover
David Wheeler wrote:
> On Oct 5, 2004, at 12:36 PM, Geoffrey Young wrote:
>
>> somewhere in here it looks like -one-process is missing, though I
>> wouldn't
>> know where it would go.
>
>
> I'll put it in, though it isn't needed if you use A-
> +my $atdir = $self->localize_file_path("$ENV{HOME}/.apache-test");
> +local $Test::Harness::switches=
> +local $Test::Harness::Switches=
> +local $ENV{HARNESS_PERL_SWITCHES} = "-MDevel::Cover=+inc,'$atdir'";
somewhere in here it looks like -one-process is missing, though
David Wheeler wrote:
> On Oct 5, 2004, at 11:32 AM, Geoffrey Young wrote:
>
>>> Ah, cool. But $(HOME) doesn't correspond to ~/ here, does it?
>>
>>
>> yeah - it's equivalent to $ENV{HOME} in make-land. I guess there is
>> always
>> the dan
>>test-cover ::
>> @cover -delete
>> @HARNESS_PERL_SWITCHES=-MDevel::Cover=+inc,$(HOME)/.apache-test
>>APACHE_TEST_EXTRA_ARGS=-one-process $(MAKE) test
>> @cover
>
>
> I wonder whether we shouldn't try to standardise the target name before
> it's too late to do so. Module::Build
>> - HARNESS_PERL_SWITCHES gets Devel::Cover started
>
>
> Module::Build's testcover target already does this.
:)
>
>> - +inc,$(HOME)/.apache-test keeps coverage away from generated A-T
>> files,
>> which isn't required
>
>
> Ah, cool. But $(HOME) doesn't correspond to ~/ here, does it?
David Wheeler wrote:
> On Oct 2, 2004, at 2:30 PM, Geoffrey Young wrote:
>
>> I started to maintain Apache-Test skeletons, but I never quite got
>> them up
>> to speed. give me a few days and I'll roll a tarball with a test-cover
>> target so that folks ca
Geoffrey Young wrote:
>>[ Just before sending this I notice Geoff has recommended something
>>better, but I'll send this too as another WTDI. ]
>
>
> cool :)
>
> I started to maintain Apache-Test skeletons, but I never quite got them up
> to speed. give me
> [ Just before sending this I notice Geoff has recommended something
> better, but I'll send this too as another WTDI. ]
cool :)
I started to maintain Apache-Test skeletons, but I never quite got them up
to speed. give me a few days and I'll roll a tarball with a test-cover
target so that folk
Kevin Scaldeferri wrote:
>
> On Oct 2, 2004, at 12:36 PM, Geoffrey Young wrote:
>
>>>
>>
>> we use Apache-Test, which starts the server, runs the tests, and shuts
>> down
>> the server again.
>
>
>
> When I last talked with you about Apa
> if you haven't investigated Apache-Test yet, I would. our custom make
> target look like this:
I forgot to add some A-T specific stuff :)
t/conf/modperl_extra.pl:
if ($ENV{HARNESS_PERL_SWITCHES}) {
eval {
require Devel::Cover;
Devel::Cover->import('+ignore' => 't/response/'
Kevin Scaldeferri wrote:
>
> On Sep 21, 2004, at 1:30 PM, Kevin Scaldeferri wrote:
>
>>
>> So, I don't expect anyone to try to figure out this stack trace stuff,
>> but I'm curious if other people have seen stability problems like
>> this? Alternatively, if someone can tell me the exact logist
> You could use the values from Config.pm
paul and I were talking about this on irc, wondering if there was some
Config.pm value that would give the @INC that perl was compiled with.
neither of us could find one, and when I started poking around as to create
a patch, I fould that the logic the co
>>> return 1 if $one == $two or return 0;
>
>
> Just FYI:
>
> I always wonder why someone would write such code. IMHO this is
> unmaintainable code. I might not be an Perl expert, but I wouldn't consider
> myself a beginner either, especially not at boolean logic. And still, my
> mind canno
hi paul :)
I think this has come up before, but I'm not sure what the resolution was.
I just came across (production) code that looks like this:
return 1 if $one == $two or return 0;
in the condition coverage the second return is always false, but I suppose
that it could be argued that if the
hi all :)
Michael G Schwern wrote:
> http://mungus.schwern.org/~schwern/src/Test-Simple-0.48_02.tar.gz
>
> A new alpha release of Test::Simple/More/Builder. You can consider this
> the 0.49 release candidate. Please let me know how it goes.
just out of curiosity, what's the word on 0.49?
--Ge
> The docs may be misleading, especially as there's code in
> Test::MockObject that really should live in something like
> Test::MockModule or Test::MockPackage, neither of which exist yet.
>
> The important point is that you always have to work with the object
> returned from Test::MockObject::E
> It's your understanding. You're not mocking the class as a whole.
> You're mocking an instance. If it helps, think of prototype-based
> programming, where you don't inherit from classes, you inherit from
> other objects and selectively override or add methods on the new
> objects.
hmm, ok, I
> my $mock = Test::MockObject->new('IO::Socket::INET');
>
> $mock->fake_new('IO::Socket::INET')
>->set_false('connected')
>->mock('error', sub { 'localerror' });
>
> the goal being that when my class calls IO::Socket::INET->new($args) that it
> fails, returning my error strin
hi chromatic :)
given being pointed toward Test::MockObject::Extends last time I decided to
rework my tests to use it instead of a dozen local overrides. I immediately
ran into a little snag.
I want to override IO::Socket::INET so that a class calling it's constructor
will use my mocked object.
stevan little wrote:
> Geoff,
>
> This sounds like mock objects basically
> (http://www.mockobjects.com/FrontPage.html), although maybe on a
> smaller/more-directed scale.
hrmph. now that you mention it, yeah, it does. and there's already
Test::MockObject (which I've heard about but obviously
hi all...
I've been working on something a bit and wanted to run it by people here to
see if folks think it's a project worthy of persuing. basically the below
bit from the README kinda sums it up for me - locally wrapping lots of
routines is getting quite tedious (specifically sockets at the mom
Michael G Schwern wrote:
> http://mungus.schwern.org/~schwern/src/Test-Simple-0.48_02.tar.gz
>
> A new alpha release of Test::Simple/More/Builder. You can consider this
> the 0.49 release candidate. Please let me know how it goes.
sorry it took me so long to get around to trying this...
the
>> I just ran into a similar "problem" in POE::Driver::SysRW. For
>> portability I have a couple lines similar to
>>
>> $! = 0 if $! == EAGAIN or $! == EWOULDBLOCK;
>>
>> EAGAIN and EWOULDBLOCK are identical on most systems. In fact, one is
>> usually defined in terms of the other. They dif
> Actually, it seems that some of the patches were applied. The problem is
> that is_deeply() delegates to ->is_eq() for non deep arguments but handles
> it's own string comparison once you descend into the structure.
yes, I figured it was something like that - who hasn't been bitten by this
kin
Fergal Daly wrote:
> There are patches in the archives for this and a couple of other bugs but
> they were submitted along with another change that wasn't acceptable so they
> were never applied. A search for is_deeply should find the patches and a
> long argument,
I found some stuff about is_de
hi all
I'm not sure if this is the proper forum for reporting Test::More bugs, but
I know some of the interested parties are listening :)
use Test::More tests => 2;
is(undef,undef);
is_deeply([undef],[undef]);
# both of these should fail
is('',undef);# this fails
i
> Thanks a lot for the test cases. I think there are two separate bugs
> here, but I'm only going to take responsibility for one ;-)
:)
>
> First, mine. The problem with Foo.pm (the minimal test case) is that
> completely empty subroutines (that is subs which contain no statements
> at all) a
hi paul :)
I recently discovered an issue with nested subroutines while using
Devel::Cover with Parse::Yapp. the basic issue is that some subroutines are
not discovered by Devel::Cover and thus no metrics are generated.
there are two files in the tarball. Foo.pm is a minimal test case showing
t
> The other concern I've had with our style of xUnit testing is that we're testing
> behavior, but not
> the actual data. With Test::More, we tested against a copy of the live database
> (when possible --
> but this definitely caused some issues) and we sometimes caught data problems that
> xU
Tony Bowden wrote:
> Is there any simple way to remove the test files themselves from the
> Devel::Cover results? i.e. just see the coverage analysis of the files
> being tested rather than all the t/* files as well?
>
> We want to monitor the total coverage over time on a project, and it
> woul
> Before I get too deep into an implementation, I'd like to poll the group about
> how you would use this feature and like it to behave. My thoughts and plans follow.
>
> For the coverage summary, the numbers represent actual coverage, but the colors
> are based upon actual coverage + analysis. S
chromatic wrote:
> On Fri, 2004-05-21 at 09:02, Geoffrey Young wrote:
>
>
>>another thing that is keeping me from 100% right now is the
>>classic
>>
>> my $class = ref $self || $self;
>>
>>where the only way to satisfy the conditional is to
>> I might like to signal Devel::Cover that func() has a constant return (or
>> lack thereof).
>
>
> I don't know if I would like this feature. To me it would allow you to
> falsely skew the results of the Devel::Cover output. I look at
> Devel::Cover as a harshly objective analysis of my test-c
> Full coverage isn't always possible, and the lack of it isn't
> necessarily a problem.
I fully agree. however, once you start using a tool like this, management
will inevitably ask "what's that 93% about?" and the answer is sometimes
complex and subject to judgement: "well, Devel::Cover is j
> This is unlikely to be the only case in which I have not fully
> understood the subtleties of the op tree, and so I am grateful for
> reports such as this.
I'll keep them coming, then :)
>
> The following patch should fix it, and will be in the next release,
> hopefully coming next week:
exce
hi paul.
I've found that in a statement like
$x{foo} ||= 1;
I can't ever satisfy the first condition in the "condition coverage" matrix
(0,0) since 1 is always true. is it desirable to remove fixed truth values
like this from the truth table?
I tried taking a look at adding the condition t
95 matches
Mail list logo
