Re: qa.perl.org
1) Testing your code - I think this will need the largest amount of work. Hilary, could I ask you to have a look at this? - Are the articles the best we can link to? - Do we need those articles if we update the rest of the content. - can the test-modules.html and testing-guidelines.html be cleaned up and updated (currently in POD, but does not have to stay that way)? Will do. Thanks, Leo, for coordinating all of this... -h (posted from the road, quite literally, near High Hill, Missouri, on our way home from visiting friends and family on the east coast.P.S. There's lots of cheap billboard space for sale along I-70!) Hilary J. Holz, Ph.D. Agile Technomethodologist Director, Laboratory for Adaptive Hypermedia and Assistive Technologies, Cal State East Bay holz.hil...@gmail.com http://twiki.csueastbay.edu/People/HilaryHolz
Re: qa.perl.org
1) Testing your code - I think this will need the largest amount of work. Hilary, could I ask you to have a look at this? - Are the articles the best we can link to? - Do we need those articles if we update the rest of the content. - can the test-modules.html and testing-guidelines.html be cleaned up and updated (currently in POD, but does not have to stay that way)? Will do. Thanks, Leo, for coordinating all of this... -h (posted from the road, quite literally, near High Hill, Missouri, on our way home from visiting friends and family on the east coast.P.S. There's lots of cheap billboard space for sale along I-70!) Hilary J. Holz, Ph.D. Agile Technomethodologist Director, Laboratory for Adaptive Hypermedia and Assistive Technologies, Cal State East Bay holz.hil...@gmail.com http://twiki.csueastbay.edu/People/HilaryHolz
common errors?
On 6/23/08 11:24 PM, chromatic [EMAIL PROTECTED] wrote: (Want a heuristic which finds *actual* bugs in almost every module ever written? Check the use of eval and subsequent $@ testing, or the use of ref(), or SUPER::whatever(), for example.) Could you expand a bit, please (or provide pointers to an existing reference or references)? Sounds like you have particular common errors in mind for each of these, and off the top of my head I'm not coming up with any such references. Unfortunately, the combination of schedule and lack of funding means that I don't get to go to techie conferences since heading off into academia, so there may be slide sets, etc Hilary -- Hilary Holz, D.Sc. Co-chair, SIGCSE Committee on Teaching Computing Research Methods Director, Laboratory for Adaptive Hypermedia and Assistive Technology Associate Professor of Computer Science Department of Mathematics and Computer Science, Cal State, East Bay http://acc.csueastbay.edu/ [EMAIL PROTECTED]
Re: Devel::Cover problem with Apache::Test
Have you had D::C collect coverage stats for tests in the t/apache, t/response/TestApache format? yes. when I run the skeleton I pointed you toward last time I get this Filestmt bran condsub time total - -- -- -- -- -- -- blib/lib/Apache2/Handler.pm100.0 50.0n/a 100.0 100.0 95.0 browsing through coverage.html shows that the handler() subroutine was indeed hit and coverage recorded. do you not see similar results when running that sample? 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 uploaded that change to the published version?) The test case in the demo doesn't contain the problem I'm having, though. Tests that aren't of the very specific write-the-request write-the-response in t/apache and t/response/TestApache work fine for me, too. I have it on the run, though - It appears to be an interaction between TestMB and D::C. I have gotten it to give me correct results a couple of times - I'm currently trying to isolate/replicate the exact settings that yield correct results. One problem which I've isolated is that running ./Build testcover overrides the select/ignore settings specified via import. More info in a bit (This is fun, right? right?) Hilary -- Hilary Holzhttp://acc.csueastbay.edu/~hholz/ Assistant Professor [EMAIL PROTECTED] Dept of Mathematics and Computer Science California State University, East Bay
Re: Devel::Cover problem with Apache::Test
Hi Geoff ( Paul),
On 09/16/2005 08:54 AM, Geoffrey Young [EMAIL PROTECTED] wrote:
Apache-Test-based distribution. the first is the addition of
t/conf/modperl_extra.pl which (for anyone searching the archives) contains:
if ($ENV{HARNESS_PERL_SWITCHES}) {
[snip - ah, helpful, now I understand how to use the testcover target]
the second part is that you need to alter t/conf/extra.conf.in so
HARNESS_PERL_SWITCHES is passed to the underlying mod_perl process. the line
[snip - don't need under Module::Build, as testcover target does this part
of it for you]
Well, I've learned something, but I still have the same problem. Sigh.
I'm running under Module::Build, using the testcover target. Devel::Cover is
collecting coverage statistics on the modules, it's just collecting
reporting wildly incorrect statistics (see below). 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) while reporting that
subroutines for which I have tests are uncovered. I realize that
Devel::Cover is alpha code, I'm just hoping that this is a configuration
problem, not a bug :-/
Thanks for the help,
Hilary
-- -- -- -- -- --
File stmt bran condsubpod time
-- -- -- -- -- --
...ache/Acut/AdminHandler.pm 75.0n/an/a 87.5 100.05.9
...Acut/AdminHandler/Base.pm 13.01.72.0 42.1 100.0 15.6
...t/AdminHandler/Comment.pm8.30.00.0 30.0 100.01.6
...AdminHandler/Component.pm7.00.00.0 27.3 100.02.2
.../AdminHandler/Metadata.pm8.80.00.0 30.0 100.01.7
...t/AdminHandler/Request.pm 39.60.00.0 70.0 100.06.7
...Acut/AdminHandler/User.pm5.20.00.0 23.1 100.01.8
...ache/Acut/Authenticate.pm 36.00.0n/a 54.5 100.01.7
...ib/Apache/Acut/Cluster.pm 100.0n/an/a 100.0n/a1.3
...ib/Apache/Acut/Comment.pm 100.0n/an/a 100.0n/a0.8
...Apache/Acut/ConfigData.pm 12.00.0n/a 12.5 100.00.3
...b/Apache/Acut/Database.pm 85.6 63.0n/a 78.6 100.0 48.1
...che/Acut/Database/Test.pm 90.9n/an/a 85.7 100.05.2
...Apache/Acut/TutHandler.pm 92.3n/an/a 80.0 100.01.3
...b/Apache/Acut/Tutorial.pm 100.0n/an/a 100.0n/a2.1
--
Hilary Holzhttp://acc.csueastbay.edu/~hholz/
Assistant Professor [EMAIL PROTECTED]
Dept of Mathematics and Computer Science
California State University, East Bay
Re: Devel::Cover problem with Apache::Test
I've noticed that Devel::Cover reports wildly different results depending on the contents of @INC within the test files. Do you set search paths within the files? Apache::Test sets the path (use lib '/yada/blib/lib') in modperl_inc.pl, generated as part of the testing configuration. So the search path has been set before the .t files run. Don't see how that would cause Devel::Cover to report 100% statement coverage of a file that has never had anything but a use executed on it during testing, though. Hmmm... Hilary -- Hilary Holzhttp://acc.csueastbay.edu/~hholz/ Assistant Professor [EMAIL PROTECTED] Dept of Mathematics and Computer Science California State University, East Bay
Devel::Cover problem with Apache::Test
I'm trying to figure out why the coverage reports I'm getting from Devel::Cover (well, cover...) aren't recognizing the effects of most of my testing. A simple example is one module for which Devel::Cover doesn't record any subroutine coverage, yet I have tests for each of the subroutines that run just fine. I put use Devel::Cover Configuration particulars: Apache::Test qw(:withtestmore), mod_perl 1.29 (I added use Devel::Cover to modperl_extra.pl per instructions), apache 1.3.33, Devel::Cover 0.54, perl 5.8.6, fedora core 5. Oh - Module::Build. I'm collecting coverage via ./Build testcover. (version control via subversion, but I'll eat my hat if that's an issue) I notice that the modules on which I'm using 'simpler tests' (as it were) seem to be working-and-playing fine with Devel::Cover. Most of the tests, though, are of the custom-request-and-response Apache::Test format - those appear to be the ones Devel::Cover is missing. I'm trapping and propagating errors (eval and die) - I wouldn't mention it but that's another difference between the modules in which Devel::Cover recognizes the testing and those in which it doesn't - the modules which don't trap and propagate yield believable numbers. 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. Help? Hilary -- Hilary Holzhttp://acc.csueastbay.edu/~hholz/ Assistant Professor [EMAIL PROTECTED] Dept of Mathematics and Computer Science California State University, East Bay
