Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re: Favourite modules March 2004

by dragonchild (Archbishop)
on Mar 08, 2004 at 02:26 UTC ( #334705=note: print w/ replies, xml ) Need Help??


in reply to Favourite modules March 2004

The enormous number of tests also made me like it a little less: it takes too long to install.

This statement made me pause. Why are a large number of tests a "Bad Thing"(tm)? I would think that more tests would imply better code. (I am not naive enough to think it ensures better good, but if two pieces of code were in front of me and 1 passed 100 unique tests and the other 1000 unique tests, I'd be more confident initially with the latter ...)

Plus, don't you install each distribution only once in a while?

------
We are the carpenters and bricklayers of the Information Age.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.


Comment on Re: Favourite modules March 2004
Re: Re: Favourite modules March 2004
by Juerd (Abbot) on Mar 08, 2004 at 10:35 UTC

    Why are a large number of tests a "Bad Thing"(tm)?

    They become a bad thing when you have 157732 tests for 2245 lines of code. That is 70 tests per line of code, while of course a lot of lines don't even contain any logic. make test for Regexp::Common takes too long. I've already met a sysadmin who refused to install it because of that and I'm slowly becoming one myself.

    if two pieces of code were in front of me and 1 passed 100 unique tests and the other 1000 unique tests, I'd be more confident initially with the latter

    Of course, but do you really need thousands of tests for zipcodes? Are these thirty six thousand tests really needed for a palindrome regex?

    Plus, don't you install each distribution only once in a while?

    Yes, but I dislike this test suite that takes minutes to run for the same reason I dislike compiling from source. I am lazy and impatient and that is exactly why I like Perl.

    There's only one thing regarding testing that I dislike more than an exaggerated test suite like Regexp::Common's and that is not having tests at all. I think R::C could do with only, say, a tenth or maybe a hundredth of its current test suite. For development, a huger one might be nice, but 1.5e5 tests on installation is more than I'd like.

    Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

      I'm still confused. What's wrong with kicking off an installation and going to get a cigarette or a cup of coffee? Kick it off, then go to lunch. Or, kick it off at home and go watch the latest SG-1 episode ... That's what I do when I'm installing OSes or Apache, and those take over an hour each. *shrugs* I guess that it seems a little too impatient, in my book.

      And, frankly, I don't think that thousands of tests for regexes is ridiculous. It's extremely easy to get them every-so-slightly wrong. Abigail-II is right, imho, to provide that kind of coverage. Those regexes are going to be depended on for business decisions. It might be a small part, but it's nice to know that "It Will Just Work".

      And, the test suite on installation isn't always just for installation. I've played with making changes to many modules. I use their test suite for making sure my changes are backwards-compatible.

      Now, maybe it might be useful for "make test" to have a "make test TEST_TYPE=dev" vs. "make test TEST_TYPE=install" (which would be the default). Then, the tester would indicate a subset of tests which are regression-only and which ones should always run.

      Plus, you can install the distribution without running the test suite ...

      ------
      We are the carpenters and bricklayers of the Information Age.

      Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

      Hmm, I just installed it and it only took about 60-90 seconds or so. That's not a big problem AFAIC.

        Now try doing it on a loaded server system. I had to upgrade R::C recently and timed the upgrade process. The exact numbers I forgot, but the tests took several minutes.

        Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

Long module install times (Re: Favourite modules March 2004)
by jonadab (Parson) on Mar 08, 2004 at 23:40 UTC
    Plus, don't you install each distribution only once in a while?

    Define "once in a while". I install CPAN modules less often than I use them, but I don't very often go a week without installing some modules off of CPAN onto one or more of the various computers that I use or administer at home or at work. Long install times are annoying, annoying enough that I have developed this little habbit of doing screen -R CPAN, starting the install, detaching, and doing something else for a while. But I can't continue to work on whatever I was doing until the install finishes. I wish more of the modules on CPAN were pure Perl so they wouldn't take so long to install. It is my sincere hope that in Perl6 XS will be unnecessary and heavily deprecated.


    ;$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,".rekcah lreP rehtona tsuJ";$\=$;[-1]->();print

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://334705]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (3)
As of 2014-09-21 02:21 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (165 votes), past polls