On Mon, Dec 17, 2001 at 04:10:30PM +0900, Tatsuhiko Miyagawa wrote:
> On Sat, 15 Dec 2001 09:10:33 -0500
> Barrie Slaymaker <[EMAIL PROTECTED]> wrote:
>
> > Now I see what you're after with the -M approach, thanks for the
> > example.
>
> Cool.
>
> > I can understand that :) since CPAN is/seems a non-started for a
> > significant number of folks (I have a Win32 system that it's
> > nonfuncitonal on; haven't debugged it yet).
>
> I think Test::Differences is mainly for module developpers,
We'll have to agree to disagree; I'd rather get test failure reports
with more explanatory test output than less explanatory output. As
Schwern points out, there's always the t/lib/Test/Differences.pm, use
lib "t/lib"; approach if you want to make their lives easier. That's a
bit more work on your part (ie keeping up with Test::Difference
releases), and I can't blame anyone for not wanting more work :).
> not for module users, thus the necessity for Test::Differences would
> be better optional in distributing modules.
I don't want to get in the business of overloading every future Test::*
module's ok() (from Test.pm) and is_deeply() (from Test::More)
equivalent. So I going to have to suggest that you do something like
(tested):
use Test;
eval "use Test::Differences";
sub my_ok {
goto &eq_or_diff if defined &eq_or_diff;
goto &ok;
}
plan tests => 1;
my_ok "a", "b";
That preserves line number reportage and gives you the flexibility you
desire without the maint. hassle of tracking Test::Differences'
releases.
I've added this to the docs, thanks for pointing out the need.
- Barrie
