Skip Menu |
 

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Devel-Cover CPAN distribution.

Report information
The Basics
Id: 16222
Status: open
Priority: 0/
Queue: Devel-Cover

People
Owner: Nobody in particular
Requestors: sargie [...] cpan.org
tylerm [...] activestate.com
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)



Subject: Regular expressions have conditions too!
Download (untitled) / with headers
text/plain 907b
Hello, I've been using Devel::Cover for a few months now and I love it. It's made it *way* easier to write clean, bug-free code and unit tests. One thing that just occured to me while writing a validator as a regular expression, is that regexp's have conditions too. I don't know how easy it would be to get this functionality in, but given a regular expression like: qr/something|someotherthing/ I think it would be helpful to have coverage analysis showing you which parts of the regular expression got matched. With more complicated regular expressions, like qr/(1|2|(456|654))|((?:(1|2)|(3|4))456(7|8))/ I could see the specification for what was matched and what wasn't getting really long (and it probably wouldn't be appropriate to use the same "A B C D" notation as standard code conditions). What do you think? Is this feasable? Insane? Thanks, Tyler
Download (untitled) / with headers
text/plain 186b
Yes, this is true. Regular expressions are their own little language and could be covered too. But this is not something I'm planning on doing right now. It's on the TODO list though.
Subject: Substitutions with /e
Download (untitled) / with headers
text/plain 188b
Either the Tutorial is wrong in saying: "100% branch coverage implies 100% statement coverage." OR s/foo/bar()/e; should flag as a branch not followed if bar() is not executed... +Pete
Subject: Re: [rt.cpan.org #21975] Substitutions with /e
Date: Sat, 30 Dec 2006 01:02:51 +0100
To: via RT <bug-Devel-Cover [...] rt.cpan.org>
From: Paul Johnson <paul [...] pjcj.net>
Download (untitled) / with headers
text/plain 630b
On Mon, Oct 09, 2006 at 10:17:33AM -0400, via RT wrote: Show quoted text
> Either the Tutorial is wrong in saying: > > "100% branch coverage implies 100% statement coverage." > > OR > > s/foo/bar()/e; should flag as a branch not followed if bar() is not > executed...
I think I agree with this in principle, but it's really not something I want to deal with at the moment. The TODO list mumbles something about Regular Expression coverage, and should that ever become a reality, this case should fall out from that. So I'm going to leave this as stalled until that happy day. Thanks, -- Paul Johnson - paul@pjcj.net http://www.pjcj.net
RT-Send-CC: paul [...] pjcj.net
Download (untitled) / with headers
text/plain 436b
Le 2005-11-30 22:52:30, CRAKRJACK a écrit : Show quoted text
> One thing that just occured to me while writing a validator as a > regular expression, is that regexp's have conditions too. I don't > know how easy it would be to get this functionality in, but given a > regular expression like: > > qr/something|someotherthing/
The module re::engine::Hooks may help for this task... -- Olivier Mengué - http://perlresume.org/DOLMEN


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.