On Sep 19, 2006, at 7:00 AM, David Golden wrote:
David Cantrell wrote:
clearly. So my attempt to make my tests good will mostly consist
of applying the same coding standards to the test suites as I do
to the rest of the code.
OK, Lazy Web, who's going to write Test::Test::Perl::Critic?
:-)
Yeesh, Perl::Critic tries to be self-compliant, but even we don't run
Perl::Critic on it's own test suite, let alone on Test::Perl::Critic.
In seriousness, though, that is a pretty good idea. There definitely
are different standards for writing test code than writing live
code. A set of policies optimized for judging style of test code
would be very valuable. Like, for example, policies that enforce
labeling tests if Test::More is in use.
Any tips on what - other than comprehensiveness, clarity and
maintainability - I should aim for specifically in test suites
would be greatly appreciated.
No claim to best practice here, but this some of what I aim for:
I try to reduce the amount of copy/paste test code I use. Once is
OK, but twice makes me start thinking about putting it into a
module that I pull in with "use t::Common" or something.
I try to separate my test data from my test code. Many of my test
files are data structures of test inputs, outputs, and labels that
get processed in a small loop.
I try to have the test labels be self documenting -- I'll often
throw in a pass() to help me see the flow of execution when run
verbosely
I try to have each test file test a single feature -- with minimal
dependencies on other tests being successful (not always possible).
I try to skip subsequent tests that depend on something being
successful so the real point of failure is apparent.
Those are very good points. A few more:
* Keep the .t files on topic. If you are testing independent
features, consider using a separate .t file
* Name your .t files in a lexicographic order that tests the simple
stuff (like syntax errors) first and the less important stuff (like
Perl::Critic compliance) last, with the meat in between
* Write readable test code, and comment the intentions of every .t
file
Consider that your tests are sometimes the best working example
of usage of your code.
* Use Devel::Cover, but don't assume that high coverage always
means thorough testing
* Every time you get a valid bug report, write a test that
reproduces the bug.
and of course
* Read "Perl Testing: A Developer's Notebook" for more ideas
http://www.oreilly.com/catalog/perltestingadn/
Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
(http://www.media-landscape.com/) and partners in the revolutionary
Croquet project (http://www.opencroquet.org/)
