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
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_typeSo 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.
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.pm2) 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 inThis 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.
./modperl-2.0/t/modperl
What section of code is doing this operation? I looked around but it
wasn't immediately obvious to me.
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:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
