I decided to look at my older modules and check if they still passed their test suite, and possibly upgrade it (now that I have discovered all the goodness that Devel::Cover provides). I tested them under Windows, having one of those at hand.
Here are some results, dipped in a little nostalgia (bear in mind that when the test suites were written I did know or care about test coverage):
This is the first module I ever uploaded on CPAN. Almost two years ago. *Sigh*
Barbie had the test suite fail on MSWin32. That's since I've added an IO::Select object to allow the module only user (not me) to check if there's anything to read in the log file. And guess what? The test that fail are those who check the select() method.
Could IO::Select not work under MSWin32? That's it. I checked the relevant bit of the Perl test suite, and decided that since Windows users can't use can_read() on it, they won't need the result of the select() method either. undef is all you'll get, guys.
Version 0.09 will be on CPAN later today, and hopefully, the Windows tests will pass. I've also found that the test coverage was quite good: 99.1% statement, 86% branch, 77.8% (7/9) condition, 100% subroutine, for an overall 94.5%. I'll probably add a test or two before uploading 0.09 on CPAN.
Philippe Bruhat, Jonathan Paton, Jérôme Quelin, Amir Karger, Steffen Müller and Eugène Van der Pijll worked together to create a module that would solve referees and players problems in Perl golf competitions. We more or less failed, due to lack of time and the speed of the golfing community.
Can you imagine that they didn't hold their breath waiting for us? ;-)
Er, uhm... I'll look again later. (I have yet to release 0.14, which has been waiting way too long in my CVS repository.)
This is a module I only wrote because a friend needed the data that's available on the heavens-above site. It was fun to do, and provided the meat of a lightning talk I gave at YAPC::Europe 2002, in Munich. All tests successful.
And good coverage as well: 100% statement, 91.2% branch, 87.5% (7/8) condition, 100% subroutine, for an overall 97.5%.
I created this module for work. They still used it one year later, I heard.
All tests successful on this Windows setup (though Barbie had a test failure). Test coverage: 98.9% statement, 85.7% branch, no condition, 100.0% subroutine, for an overall 96.2%.
This one's the smaller brother of the previous one. The job required parsing BlueCoat log files (it's a web appliance). I tried to be solve the broader problem of parsing arbitrary log lines with regular expressions when you can write a regexp for each fields and the field order is configurable in the application (so the log parsing script has to read the configuration to create the regexp on the fly). I came up with Regexp::Log. For a while, I planned to write Regexp::Log::Apache.
All tests successful. Test coverage: 92.2% statement, 60.7% branch, no condition, 100.0% subroutine, for an overall 86.5%. Not so good as the others.
I'd love it if someone used Regexp::Log to solve their problem.
Not looked at it today. Designed for and used by http://articles.mongueurs.net/ for syntax highlighting.
I already talk too much about this one...
I should try to at least run the test suite for all my modules once in a while.
Eh? There's a free compiler from MS for Win32 systems. Check out http://www.rubygarden.org/ruby?WindowsCompiler.
Or did you simply mean that it's unlikely they'll have a C compiler?
Re:C on Win32
BooK on 2005-01-18T17:51:17
"...and decided that since Windows users can't use C on it..."As you say, Eh? I re-read that post quite a few times, but I'm pretty sure I type can_read()...
Maybe I actually typed in some POD,like C<can_read()>. Which could explain the mixup. I'll fix this in the entry. Thanks.
Re:C on Win32
BooK on 2005-01-18T17:55:31
That was it. I typed C<...> in several places, instead of <tt>...</tt>. Why can't everything just understand POD?
Re:C on Win32
djberg96 on 2005-01-18T18:49:24
Oh, haha. I thought that was a strange sentence, so I wasn't entirely sure what you were getting at. Disregard.
:)