And though I admit the culture is great overall, that does seem to be my experience with CPAN. You never know what you're going to get. It's like that to some degree with every language but with CPAN there's so much trust in the system it can be harder to identify and filter out the lesser quality stuff.
The other way to do it is to start an HTTP server locally and use that (which is what WWW::Mechanize does)
The whole point of automating tests is so you can run them unattended: at install time, or under a continuous integration system after code check-ins, or for git pickaxe to find which change caused a bug, or whenever else you want to confirm that a whole lot of code still works as intended.
Agreed :-)
And though I admit the culture is great overall, that does seem to be my experience with CPAN. You never know what you're going to get. It's like that to some degree with every language but with CPAN there's so much trust in the system it can be harder to identify and filter out the lesser quality stuff.
There are lots of nice tools that help with that though. https://metacpan.org/, http://cpantesters.org/, http://cpanratings.perl.org/, etc.
CPAN has had many more years than Ruby's Gems to mature and develop.
There are 2560 [edit: I was wrong. 39411 is the right number] gems on http://rubygems.org/. There are 24,920 distributions on CPAN. Well over 100k modules. The automated testing infrastructure, documentation, etc. also makes it much easier to figure out what modules work on what systems and what versions of perl than in ruby land. Things like meta.cpan.org and cpantesters.org are a god send that I wish I had when I'm using other languages.
And the testing infrastructure rocks.
It's evolved so everything produces and consumes TAP (http://testanything.org/) a simple human-readable protocol for expressing pass/fail results (with standard modules that help people output and consume TAP).
This means I can write tests procedurally, or in an xUnit style, or a BDD style, or a specification-based testing style, or use various DSLs for things like exception testing or for testing web apps... and so on.
I just use the style that seems most appropriate for the thing being tested. They all output TAP. All the standard test runners consume TAP. Everything "just works" and plays nice together.
I can even easily integrate tests running in other languages or environments as long as they output TAP.
In addition - since almost all of the Perl testing modules use a common TAP output module - you can usually integrate different styles in the same test code. So, if appropriate, I can pop some specification-based tests and some friendly web-testing DSL as assertions inside my xUnit tests.
Fun :-)
Wish other languages test environments were setup this way.
That makes it easy to use a cpan module with confidence, which imo is not valued highly enough in other language communities cpan-like structures.
I misunderstood the 39411 number to be the total number of gems submitted over all time, rather than the total number of extant versions. My bad.
Also the rspec ecosystem is becoming more and more mix-and-match.
It's nowhere near as integrated as perl yet though.
I find it interesting that PHP doesn't have anything in the same league as Perl/Ruby/Python even after all these years.
Any PHP folk out there?