Geoffrey Young wrote: [...]
to use Test::More for server side tests (a la t/response/foo.pm) we need at least version 0.49, which was not even in 5.8.5. client tests can use any version of T::M as far as I know.
OK, so just the availability of T::M is not sufficient and hence my proposal is not good.
so really, if you want unlike() (or whatever) you would need to do that on a per-test basis. otherwise you would essentially be preventing a large portion of the userbase from running the test suite as a whole. I'm not entirely convinced this is unacceptable, but I'm sure you are, so I'll give in here :)
Thank you.
anyway, in the end I guess I wouldn't suggest moving to T::M entirely just yet. but if you want to use it occasionally within certain tests I think that's fine.
Of course another alternative is to bundle a sufficient version of T::M under t/.
I understand that Test::More's behavior is preferrably at run time,
yeah, that's the issue for me - t_cmp() prints out too much cruft when everything is just fine.
agreed, and we could certainly change that to match T::M's behavior, *but* I still want to be able to force it to print the verbose output even when everything is fine.
since it prints out the data only when there are problems. But how do
you develop a new test if you have no way to force Test::More to print
the compared values?
I just trust is() - if you develop tests first then it always fails until you get things right :)
I prefer to first see the output and then write the comparison test than the other way around. I don't understand why T::M doesn't allow an option to force the verbose output.
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
