Re: extending t_cmp to handle !t_cmp?
Geoffrey Young wrote: - We still don't have Test::More in the 5.6.1 core (it was added in 5.6.2/5.8.0), so we can't rely on it being available. sure, but you can conditionally skip over those tests for users that don't have Test::More installed. I know that currently doing that is kind of ugly, but we could come up with some pretty shortcuts for this if you like. Am I correct to say that Test::More is in the core for all but 5.6.1 the required minimum by mp2? so if we make a dependency on Test::More only the 5.6.1 users will have to figure out how to get this module before they can start building modperl? If we agree to go with the switch to T::M, do we have sufficient functionality with T::M shipped with 5.8.0 for example? i.e. is 5.6.1 the only perl version that we need to require users to do an extra operation or do we require a specific T::M version, in which case many other distros are affected? - Test::More's verbose output doesn't work the way we want, it prints out the expected/received values only on failure, making it really hard to develop tests. that's a matter of personal preference - I very much prefer the behavior of is() to t_cmp() :) I understand that Test::More's behavior is preferrably at run time, 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? That's the only reason why I prefer t_cmp() to is(). anyway, I understand your concerns, so go ahead and implement it if you like. it just feels really, really bad to continue moving as though the Perl community hasn't already solved these problems with what is considered to be the standard testing module. At the moment I'm fine. -- __ Stas BekmanJAm_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
Re: extending t_cmp to handle !t_cmp?
Am I correct to say that Test::More is in the core for all but 5.6.1 the required minimum by mp2? yes, but see below - we would have further version restrictions if we chose to make T::M the engine for the entire mp2 test suite. so if we make a dependency on Test::More only the 5.6.1 users will have to figure out how to get this module before they can start building modperl? they shouldn't need the dependency to build mod_perl, only to test it :) If we agree to go with the switch to T::M, do we have sufficient functionality with T::M shipped with 5.8.0 for example? i.e. is 5.6.1 the only perl version that we need to require users to do an extra operation or do we require a specific T::M version, in which case many other distros are affected? 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. 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 :) 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. 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. 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 :) That's the only reason why I prefer t_cmp() to is(). I can see that. --Geoff
Re: extending t_cmp to handle !t_cmp?
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/. that's an idea. so long as it's not installed with 'make install'. or indexed by cpan either, I suppose. 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. yeah, that's a good idea. 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. I dunno the politics here, but it might make for a nice enhancement. I'll look into it. --Geoff
Re: extending t_cmp to handle !t_cmp?
Stas Bekman wrote: Of course another alternative is to bundle a sufficient version of T::M under t/. that's an idea. so long as it's not installed with 'make install'. or indexed by cpan either, I suppose. anything living under t/ is not installed on 'make install' and not scanned by PAUSE. The only request is to do that after mp2.0 is out. -- __ Stas BekmanJAm_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
Re: extending t_cmp to handle !t_cmp?
Stas Bekman wrote: Stas Bekman wrote: Of course another alternative is to bundle a sufficient version of T::M under t/. that's an idea. so long as it's not installed with 'make install'. or indexed by cpan either, I suppose. anything living under t/ is not installed on 'make install' and not scanned by PAUSE. The only request is to do that after mp2.0 is out. agreed. no sense in messing with that now. --Geoff
extending t_cmp to handle !t_cmp?
Most of the time when one needs to check when two values are different one could run: ok !t_cmp(...) but the diagnostics is wrong, since received will be matching 'expected' For example: ok !t_cmp $received, qr/message/ # testing : whatever # expected: (?-xism:message) # received: [...] [notice] [client 127.0.0.1] message must not appear! not ok 32 so the verbose output is confusing. so we probably need to introduce a new directive t_cmp_no() or something similar which will be run as: ok t_cmp_no $received, qr/message/ and log as: # testing : whatever # expected: ! (?-xism:message) # received: [...] [notice] [client 127.0.0.1] message must not appear! not ok 32 or something like that. internally it'd run !~, neq and != depending on the arguments. Comments? -- __ Stas BekmanJAm_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
