On Sat, Dec 15, 2001 at 01:18:23PM -0500, Michael G Schwern wrote:
> On Sat, Dec 15, 2001 at 10:52:07AM -0700, chromatic wrote:
> > On Sat, 15 Dec 2001 07:10:33 -0700, Barrie Slaymaker wrote:
> >
> > > How about having Test::More use eq_or_diff_data() in is_deeply() if it cane
> > > eval "use Test::Differences;" and use it's current routine if it can't? That's
> > > as seamless as you can get.
> >
> > Wild idea:
> >
> > How about splitting out the error-reporting, with a nice default in
> > Test::Builder or wherever, using optional modules if possible?
> >
> > use Test::More
> > tests => 100,
> > report => Test::Differences;
>
> The two modules can already work together in the same script. So, if
> you have Test::Differences, which has superior complex data structure
> handling, why are you calling is_deeply() in the first place?
The reason I was suggesting an automatic remapping of is_deeply() to be
eq_or_diff_data() inside Test::More is so that you can write a script
that only uses Test::More, but if you install Test::Differences, you get
the fancier output.
This would address Tatsuhiko Miyagawa's issue of wanting to minimize the
prerequisites (and thus the hassle) for CPANed modules, yet leverage
Test::Differences when needed.
A snippet of code is worth a kiloword, so this is what I mean. First,
rename sub is_deeply to sub _is_deeply in More.pm, then something like:
eval <<'EOCODE1' || eval <<'EOCODE2' ;
require Test::Differences;
sub is_deeply {
goto &eq_or_diff_data;
}
1;
EOCODE1
sub is_deeply {
goto &_is_deeply
}
EOCODE2
or equivalent is what I mean.
Seems very DWIMmerly to me, but YMMV, of course :).
Whether or not you want to alter Test::More's API to offer pluggable
reporting modules is another question; I'm not deeply concerned about
that.
- Barrie
