httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: extending t_cmp to handle !t_cmp?
Date Mon, 29 Nov 2004 15:07:20 GMT
Geoffrey Young wrote:
> to use Test::More for server side tests (a la t/response/ 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     mod_perl Guide --->

View raw message