You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Lyle Brooks <br...@deseret.com> on 2003/01/15 23:26:07 UTC
[mp2] tests : Is this how test should be added?
I thought I'd help out with some of the mp2 documentation, and
as part of that effort, I thought I'd try to write some tests.
The idea being that it'd be a nice if the documentation reflected
how the code actually worked. :-)
So I thought I'd try writing my first test script and adding it
to mp2 distribution.
Below I've appended a simple test script that checks the $r->content_type
method.
I have a couple of questions about it.
1) Does it look right? If I'm going to add test scripts, no sense
getting off on the wrong foot.
2) I put it in a file called
./modperl-2.0/t/response/TestModperl/content.pm
I noticed that these modules in this directory seem to generate .t
files in
./modperl-2.0/t/modperl
What section of code is doing this operation? I looked around but it
wasn't immediately obvious to me.
3) The script seems to blow if I try to $r->content_type(undef). I
don't know why you want to do this, but I thought it should be handled.
...or do I just have a bug in my test script?
Does that mean I need to add some code into mp2 to handle this case? :-)
Thanks for any feedback.
package TestModperl::content;
use strict;
use warnings FATAL => 'all';
use Apache::RequestRec ();
use Apache::Test;
use Apache::Const -compile => 'OK';
sub handler {
my $r = shift;
plan $r, tests => 4;
my $foo = 'text/foo';
my $gif = 'image/gif';
my $type = $r->content_type;
ok $type;
$r->content_type($foo);
ok($foo, $r->content_type); # Does it return what we set it to?
ok($foo, $r->content_type($gif)); # Return previous type?
ok($gif, $r->content_type); # How about now?
$r->content_type(undef); # Can we undef this?
ok(!defined($r->content_type)); # Does undef work?
Apache::OK;
}
1;
__END__
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] tests : Is this how test should be added?
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Lyle Brooks wrote:
>> What section of code is doing this operation? I looked around but it
>> wasn't immediately obvious to me.
[...]
> The code that generates it is easy to find, look at the caller trace in
> one of the .t files that were autogenerated. e.g. t/api/request_rec.t
to save you a trouble:
grep -Inr 'print GET_BODY' Apache-Test
Apache-Test/lib/Apache/TestConfigPerl.pm:87:print GET_BODY "/$pm";
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] tests : Is this how test should be added?
Posted by Stas Bekman <st...@stason.org>.
Lyle Brooks wrote:
> I thought I'd help out with some of the mp2 documentation, and
> as part of that effort, I thought I'd try to write some tests.
That's a very helpful thing to do. We need many more tests.
> The idea being that it'd be a nice if the documentation reflected
> how the code actually worked. :-)
+1
> So I thought I'd try writing my first test script and adding it
> to mp2 distribution.
>
> Below I've appended a simple test script that checks the $r->content_type
> method.
>
> I have a couple of questions about it.
>
> 1) Does it look right? If I'm going to add test scripts, no sense
> getting off on the wrong foot.
pretty much ok, though it's helpful to use Apache::TestUtil::t_cmp, which
makes it easier to debug things. See the "fixed" version of your script
and run it with t/TEST -v api/content_type
> 2) I put it in a file called
>
> ./modperl-2.0/t/response/TestModperl/content.pm
Since it's an Apache API method it belongs to TestAPI and better use the
real method name as the filename, hence I've put the fixed version into
TestAPI/content_type.pm
> I noticed that these modules in this directory seem to generate .t
> files in
>
> ./modperl-2.0/t/modperl
>
> What section of code is doing this operation? I looked around but it
> wasn't immediately obvious to me.
This is just for practicing the hibrus. When you write the test on the
server side the client simply fetches the output. In many other cases you
have to write the client side by yourself because you want to send
something and verify what was return, something that can't be done on the
server side.
When .t doesn't exist (with the same base name) it's autogenerated when
you run t/TEST -conf
The code that generates it is easy to find, look at the caller trace in
one of the .t files that were autogenerated. e.g. t/api/request_rec.t
Also you should be aware that a special section is automatically added to
t/conf/httpd.conf (on t/TEST -conf) and can be controlled from the __END__
section of the package name. More in the Apache::Test guide.
> 3) The script seems to blow if I try to $r->content_type(undef). I
> don't know why you want to do this, but I thought it should be handled.
How does the 1.0 version handle that?
> ...or do I just have a bug in my test script?
I've simply put an eval around it.
package TestAPI::content_type;
use strict;
use warnings FATAL => 'all';
use Apache::RequestRec ();
use Apache::TestUtil;
use Apache::Test;
use Apache::Const -compile => 'OK';
sub handler {
my $r = shift;
plan $r, tests => 5;
my $foo = 'text/foo';
my $gif = 'image/gif';
my $type = $r->content_type;
ok $type;
# Does it return what we set it to?
$r->content_type($foo);
ok t_cmp($foo, $r->content_type, "set / get");
# Reset and test
ok t_cmp($foo, $r->content_type($gif), "return prev val");
ok t_cmp($gif, $r->content_type, "a new val");
# Does undef work?
eval {
$r->content_type(undef);
};
ok $@;
Apache::OK;
}
1;
__END__
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org