The size of your test plan is really a function of the size of your project, and the level of complexity. I'll offer my own experiences in writing tests while working on Krang a while back.

Krang is a large system, written almost entirely in object-oriented perl. Each Krang::* package we wrote has a corresponding test file, responsible for testing all aspects of that package's interface, ensuring that we have a basis for making sure future revisions don't break existing functionality. At least, that's the boilerplate text.

In reality, fully testing packages is HARD. Especially higher-level ones, which depend greatly on lower level packages. By the point you start testing higher-level functionality, you've got a very complex system, and shining a light into every last corner to confirm that things are ok is a lot of work.

What I took away from the project is this - the more time you put into testing your lower-level modules, the more payoff you get in the end. These packages are generally easier to test comprehensively, and it simplifies your higher-level tests - you can work from the basis of knowing your underlying structure is stable.

So what to test? Simple. Every time I create a new package, I do the following:

• POD out the initial API.
• Write tests to instantiate the object, rudimentary isa_ok() and can_ok() tests. Obviously, these fail.
• Code the constructor & accessor-mutators, so that the above tests pass.
• Test initial functionality.
• Write code so the above tests pass.
• Repeat as needed.

Some of you will recognize this as being right out of Kent Beck's book on Test Driven Development, and you're right. It's worked quite well for me in several areas:

• Writing tests is a great way to discover whether your planned API is useful, or clunky.
• When I'm done with 1.0, I have a full test suite for my code.
• My level of fear when it comes to developing 1.01, 1.1 or 2.0 is greatly reduced - the tests let me know if I've broken things.

As a side note - in addition to Test::Harness and Test::More, check out Test::MockObject - I've had some great luck with it, and I think it's going to be how I solve to always-painful problem of testing CGI applications in the future.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.