in reply to document your test files

Having some POD to give a summary of things the test file is supposed to verify is a good suggestion. (As it is, in fact, a good idea to have such a summary in any non-trival Perl source file.)

I’d be worried to find extensive documentation for individual test cases, though. Writing individual tests so complex as to require documentation strikes me as unwise. They should be too trivial to usefully document. Instead, you should strive to give your tests good names. (I suppose you could make test names also show up in POD by keeping them there using the <<'=cut' trick.)

If you’re using a framework like Test::Class to group tests, such groups would be more useful to document traditionally.

Makeshifts last the longest.

Replies are listed 'Best First'.
Re^2: document your test files
by Anonymous Monk on Jul 31, 2006 at 14:34 UTC
    I’d be worried to find extensive documentation for individual test cases, though. Writing individual tests so complex as to require documentation strikes me as unwise. They should be too trivial to usefully document.

    That implies there are millions of them; the intrisic complexity of the code won't go down. You'll either: (a) have complex tests, (b) have millions of simple tests, hopefully with no gaps in them, (c) have to write code to autogenerate tests, or (d) leave important chucks of code untested.

    I don't think there's any silver bullet there. I do know that in most cases, self-documenting code isn't.

[reply]

In Section Meditations