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
Re: Apache::TestRequest + Cookies
Christopher H. Laco wrote:
Now that I've gotten a few other module updates out of the way, I want
to get back to the thought of cookies within A-T. Two things were
mentioned that would help the A-T project in some way.
First, possibly add pod doc on how to use cookies within A-T using
Michaels solution of
Apache::TestRequest::user_agent( cookie_jar = {});
+1
and possibly others. I would also probably take a stab at getting some
of the other things in
http://perl.apache.org/docs/general/testing/testing.html into the pod;
specifically the use of the secondary param in the GET request to add
outgoing headers and the like.
+1
Second, add some sort of cookie tests to the A-T test suit. I'm not
quite sure what a test would be for other than to verify that A-T using
LWP actually receives and sends cookies and verifies they get remembered
between requests. But that seems more like testing LWP and A-T to me.
just a very simple test that verifies that the documented technique works.
later on it may evolve to include a special A-T API if we ever add one.
My first thoughts are to keep it as simple as possible and check for
mod_usertrack. It it's there, ensure the first tracking cookie value is
maintained across multiple requests.
Whatever you find the best is fine with us. You may want to use the
same_interp framework in case you need to make sure that you hit the same
perl interpreter (in case you store some data on the server side). See the
tests in modperl-2.0/t for examples.
--
__
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
