Re^2: RFC: Test::Cases -- Worth releasing?

That's an interesting approach. I've tried similar things at times but usually found that maintaining the separate files meant more work keeping my inputs and outputs in sync -- but I could see that approach being better if the files themselves are particularly long.

As for diff, I actually use Test::Differences instead of Test::More's is() (but only if it's available so end users won't need Test::Differences as a dependency) to give me that kind of comparison, but I could see that direct access to diff would make some complex cases easier to figure out. (I wish I could get unified context diffs from Test::Differences.)

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Comment on Re^2: RFC: Test::Cases -- Worth releasing? Select or Download Code

Replies are listed 'Best First'.
Re^3: RFC: Test::Cases -- Worth releasing? by sgifford (Prior) on Sep 16, 2005 at 16:49 UTC
Yeah, I tend to use this for test that have a few hundred lines of output, which are useful for testing the final results of a system. For example, I often generate complete HTML pages to make sure everything in a Web application has worked properly. One trick that's nice is if I know what's changed, I can see if there are any differences besides that with some shell cleverness. For example, if I've added an output field called `some_thing` to my test file, and the only thing that should have changed is the addition of that one field, I can run something like: `diff -u <(grep -v some_thing test1.test) test1.ok` [download]	[reply] [d/l]

Replies are listed 'Best First'.

Re^3: RFC: Test::Cases -- Worth releasing?
by sgifford (Prior) on Sep 16, 2005 at 16:49 UTC

Yeah, I tend to use this for test that have a few hundred lines of output, which are useful for testing the final results of a system. For example, I often generate complete HTML pages to make sure everything in a Web application has worked properly.

One trick that's nice is if I know what's changed, I can see if there are any differences besides that with some shell cleverness. For example, if I've added an output field called some_thing to my test file, and the only thing that should have changed is the addition of that one field, I can run something like:

  diff -u <(grep -v some_thing test1.test) test1.ok
[download]

[reply]
[d/l]