Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Friday April 17, 2009
08:53 AM

Fun Numbers - Ruby and Perl

[ #38818 ]

From Tim Bunce's Perl 5 Myths talk: Perl 5.10.0 has 78,883 core tests.

Ruby has about 1,400.

1,400.

So Perl 5 core test suite has about 50 times as many tests as Ruby. So who has the testing culture again? It's not entirely a fair comparison because it's not asserting how many features each language has, but I doubt that Ruby is so feature poor to justify Perl having more than 50 tests for every 1 of Ruby's.

Hello, core Ruby developers! You've got an awesome language there. Could you start testing, please? Your community seems to do OK. Why not you?


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Fun Numbers - Ruby and Perl 18 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • What happens if you add CPAN tests to that count? And whatever is the Ruby equivalent.

    • Tough to say. According to Tim's slides, if we include bundled libraries, we drop significantly to a 7 to 1 advantage for tests. However, there's no clear way I can see to design a reasonable metric for non-core tests. LOC/test is silly, particularly since core Ruby seems to generate terser code than core Perl for similar functionality. Tests per function point would be difficult to analyze without static analysis of function points and agreement on said analysis.

      To be fair, even the core tests might be

      • Was thinking also about things like CPAN Testers. 3,592,446 public test reports (as of last night) vs ???.

        At least as evidence of a "testing culture". :-)

        -- dagolden

        • Heh :)

          I'm unaware of any other language community having anything remotely comparable.

          • ... yet.

            Many of the repositories are within a few years of us, so it's important to not get too proud about what we have, and keep pushing ahead.

            • First, those language communities have to get serious about including systematic automated testing throughout their repositories. I hope they do, but I haven't seen it.

              • That doesn’t really affect Adam’s point. Most of the infrastructure we have was built by individual efforts, so other communities with enough sufficiently determined members could clearly duplicate it in a reasonable time frame. (My gut estimate is about 3 years all told.)

                Even if other communities show no signs of such an effort and seem to be parsecs behind, that doesn’t mean we shouldn’t still keep pushing forward as if the would-be competition were breathing down our necks.

                Even if

                • Even if that image falsely assumes that this is a competition in the first place.

                  I don't believe it is. I want to see a comprehensive and freely distributable and reusable test suite for every widely used language. That's the only way we can port them to Parrot, for example. (There's also the code quality issue. Can I assume everyone understands that by now?)

                  • Thanks for the Perl 6 numbers. Speaking of more languages to Parrot, how is JavaScript coming along? Or ECMAScript? Because Google's v8 engine is a pretty good indication that JavaScript is a potential competitor for the server side needs as well. I have been creating some benchmarks and it fairs quite well against Ruby 1.9, Python and PHP, and while I don't like reinventing the wheel or the code bloat of JavaScript when compared to Ruby, it's certainly a platform to more than watch. See k7: http://githu [github.com]

                  • Oh, I’m not talking about the size of the language core test suite. I’m talking about the things Adam appeared to be referring to, by virtue of the comment which he replied to – namely the CPAN Testers and all the attendant infrastructure.

  • Inquiring minds want to know.

    • Rakudo knows about almost 16,000 spec tests and passes just over 10,000. The total number should cross 25,000 eventually. (When Rakudo passes 16,000 spec tests, it'll be very usable.)

  • You should really check out Rubyspec: http://rubyspec.org/ [rubyspec.org]

    These are the numbers from a CI run I did just a second ago: 2541 files, 10296 examples, 33053 expectations, 0 failures, 2 errors

  • Comparing test numbers is a load of crap, and you know that. It's the sort of stupid advocacy that people complain about when applied to Perl and shouldn't be used to compare Perl favorably to anything else. It's really embarrassing when big Perl names spread this sort of shit around. It hurts the credibility of people who try to advocate Perl in a fair manner. Ruby doesn't have to lose for Perl to be useful.

    If you want to make a valid point, talk about test coverage. You know this, though. You went for a c

    • You know, you could easily have phrased that without saying "shit" and "load of crap". It's really embarrassing when big Perl names act like this.

    • Ruby doesn't have to lose for Perl to be useful.

      Who says Ruby has to lose? Who says anyone wants Ruby to lose? (Who even knows what that means?) I'd like to see Ruby much better tested. It's a nice language, but I've found its lack of a systemic testing culture very frustrating.

  • It's entirely possible that 'test' means different things for Ruby and Perl. I recently looked into what it would take to port a particular module to Ruby (because, as far as I can tell, there's no solution for parsing RTF for Ruby), and if I'd done so I would probably have had less than a tenth as many tests. The test suite for the module tested a huge number of things for no reason that I could see, such as the contents of various internal buffers during the parsing process rather than testing the output

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.