Back to Home

Yet Another Perl Conference 2005

Testing, other perl frameworks, and the looming threat of Perl 6 and Apache 2.0 migration.

Though the summary below may be enough, I have notes for Monday, Tuesday, and Wednesday.

Summary

Testing

This is the most certain conclusion we arrived at: our testing could be done much better. A rather large portion of the people and projects we heard from here were focusing on testing not only as quality assurance, but as a working spec of sorts, and even development guidlines. ("Want a feature added to Pugs? Write a test for it, and I'll see that fail and eventually make it pass," says one of the devs.)

The ideal system sounds to me to be like this three step system:

1. A nightly (at least) smoke uses a central script to test formatting/compilation/pod stuff, plus running all of the file-specific tests that live in their own .t files. Put into these anything we want to write, and anything that ever goes wrong.
2. The results of this smoke get processed by Test::TAP::HTMLMatrix, which produces a large html table that visually shows files and the tests that pass/fail/skip/fail-expected/pass-unexpected. Check this frequently for regression, and places to make progress.
3. The testing code should make use of Devel::Coverage. This will give us information on how much of our code is actually being tested. This can be used to drive test-creation either by devs as new code is created or by devs/undergrads/testing staff who are just looking for areas that need more unit tests.

An additional slickness we should look into is using Apache::Test and Test::WWW::Mechanize to do some page level testing as though we were a client. It looks like it might be tough to get our whole framework shoehorned into the little once-off apache environments that Apache::Test uses, but it'd be interesting to see.

Frameworks

There was one major talk on frameworks, the other Catalyst being one of them. We *really* need to change our name now.

After watching this presentation on all three, it really looks to me as if they are attempting to solve a completely different problem than we are. These are built to allow basic things fast. We, though I never would have guessed it, appear to be much more industrial strength. I feel as if a well-done release of our framework could generate a significant amount of interest in this crowd. Patrick and I spent a whole dinner coming up with dramatic ways to show off the benefits of our framework, and they seemed pretty plausible.

Another note - one of the most painful things I heard said was "Catalyst's major drawback is the difficulty in figuring it out based on their docs." We must avoid this!

May I suggest you read Wednesday's Notes for more on the framework talk?

Back to Home