Dear Monks,

I'm finding a lot of my testing boils down to taking some input, manipulating it, and comparing it to some output. It's fairly simple to put the inputs and expected outputs in a data structure and loop over them (c.f. my coment in Re^2: Wanted, more simple tutorials on testing). However, as I add cases, the data structure winds up dominating the test file and managing it or finding things in the middle when a case fails become challenging.

One option to clean it up a bit is putting cases into the __DATA__section and pulling them out from there. This is the approach that Test::Base takes. Test::Base is really cool, but I'd rather avoid that because it's a Spiffy module and I wouldn't want that as a dependency just to test something I wrote that isn't using Spiffy already.

What I've been doing lately instead is sticking my test cases into individual files in a subdirectory, and then iterating over them as so:

For each file:

• Slurp the file
• Split it on a separator string into "input" and "expected"
• Process the input
• Compare processed input to expected output with a Test::More function like is(), using the name of the file as the test label

Rather than repeating that in every test file, I've put it into a test helper module that also:

• Does sanity checks that a target directory exists, is readable, etc.
• Searches the directory recursively to assemble a sorted list of files
• Sets the plan to the number of files if a plan hasn't already been defined
• Takes a callback for the input processing function -- e.g. transforming it directly or using it as a parameter to some other function

It would be fairly trivial to package this up as a module for CPAN and add some additional callbacks so that it manages the file manipulation and users only have to provide processing functions and a test function if the default is() test isn't what's needed.

It's not really doing all that much -- but it does avoid having to write the same helper code over and over for common input/output testing and makes managing test cases as simple as manipulating small text files in a directory tree. Is there demand for this? Would people find it useful enough to include as a dependency with their own modules? (Have I overlooked some existing test module that does this already?)

For a name, I'm considering just Test::Cases or maybe Test::Casefiles. Other ideas?

Thanks,

---

---

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.