[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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2] tests : Is this how test should be added?
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 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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2] tests : Is this how test should be added?
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 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
how to gracefully resolve problems in bad filters?
Any filter must always send something down-stream, this something should be at least an empty bucket brigade. If the input filter doesn't send anything down the stream, apache asserts: [Thu Jan 16 15:49:56 2003] [crit] [Thu Jan 16 15:49:56 2003] file http_protocol.c, line 1915, assertion "!(((&(bb)->list))->next == (struct apr_bucket *)((char *)((&(bb)->list)) - ((long) (((char *) (&(((struct apr_bucket*)((void *)0))->link))) - ((char *) ((void *)0))" failed and segfaults: #0 0x402f58b1 in kill () from /lib/i686/libc.so.6 #1 0x402f56a8 in raise () from /lib/i686/libc.so.6 #2 0x402f6a96 in abort () from /lib/i686/libc.so.6 #3 0x080c2c5b in ap_log_assert () at log.c:716 #4 0x08097281 in ap_get_client_block () at http_protocol.c:1893 #5 0x405f5eab in mpxs_ap_get_client_block (my_perl=0x8d27968, r=0x8d6da48, buffer=0x8be8a84, bufsiz=8192) at /home/stas/apache.org/modperl-2.0/xs/Apache/RequestIO/Apache__RequestIO.h :139 #6 0x405f6681 in XS_Apache__RequestRec_get_client_block (my_perl=0x8d27968, cv=0x8711934) at RequestIO.xs:45 #7 0x404ca9c7 in Perl_pp_entersub (my_perl=0x8d27968) at pp_hot.c:2603 #8 0x404a7afd in Perl_runops_debug (my_perl=0x8d27968) at dump.c:1394 #9 0x404517a1 in S_call_body (my_perl=0x8d27968, myop=0xbfffefe0, is_eval=0) at perl.c:1931 #10 0x4045134d in Perl_call_sv (my_perl=0x8d27968, sv=0x8d73d08, flags=4) at perl.c:1849 #11 0x40410712 in modperl_callback (my_perl=0x8d27968, handler=0x8c8dac8, p=0x8d6da10, r=0x8d6da48, s=0x8118a90, args=0x8d626b4) at modperl_callback.c:53 #12 0x40410e05 in modperl_callback_run_handlers (idx=6, type=4, r=0x8d6da48, c=0x0, s=0x8118a90, pconf=0x0, plog=0x0, ptemp=0x0) at modperl_callback.c:185 ... which is not so nice. For streaming filters we could have a flag that will be off if nothing was printed, but there is no way to know whether the filter is implemented using the streaming api or not. More-over one can switch APIs in the same filter. If this flag is on, we could send an empty bb downstream. I suppose that things similar with output filters. I'll add a test that reproduces a problem (but commented out) and if anybody has an idea how to handle it gracefully, please speak up. __ 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
rfc: new filtering APIs
[cross-posting dev/users list, since I'm not sure whether all those who
can give a useful input are on the dev list]
I've implemented a few filtering APIs recently. Rather than prototyping in
Perl I've decided to go with C from the very beginning since most of the
code was there already thanks to Doug.
I'd like to hear your comments on these. I'm listing the examples where
you can see these new APIs in action, because I don't want to change the
docs till the APIs are stabilized. To see these examples you will have to
get the mod_perl cvs, since some were added just recently. See:
http://perl.apache.org/download/source.html#2_0_Development_Source_Distribution
If you haven't played with filters yet, you read on them here (though the
docs aren't updated to accomodate for the recent code changes):
http://perl.apache.org/docs/2.0/user/handlers/filters.html
So here are the new APIs:
1. $filter->ctx
store/retrieve the filter context. Used to store things which persist
through filter invocations. E.g. chunks of data that weren't flushed at
the previous filter invocations. For examples see:
t/filter/TestFilter/in_str_msg.pm
t/filter/TestFilter/out_str_ctx.pm
t/filter/TestFilter/out_bbs_ctx.pm
t/filter/TestFilter/in_str_sandwich.pm
t/filter/TestFilter/in_bbs_body.pm
t/filter/TestFilter/in_bbs_msg.pm
t/filter/TestFilter/out_bbs_basic.pm
t/filter/TestFilter/out_str_api.pm
t/filter/TestFilter/in_str_consume.pm
basic usage:
my $ctx = $filter->ctx; # read
$ctx->{invoked}++;
$filter->ctx($ctx);# write
or simple do something once:
unless ($filter->ctx) {
# do something once
$filter->ctx(1);
}
$ctx in $filter->ctx($ctx) can be a scalar or a reference.
2. $filter->seen_eos
This will work only in stream filters (both: input and output), which read
the data in a while() loop, so the eos is detected. This flag allows to
append data to the end of stream, or perform some actions at the end of
the stream, e.g. flushing remainders of data stored in $filter->ctx.
This is a read-only accessor function.
See usage examples in:
t/filter/TestFilter/out_str_reverse.pm
t/filter/TestFilter/out_str_ctx.pm
t/filter/TestFilter/in_str_sandwich.pm
t/filter/TestFilter/in_str_consume.pm
3. You can now write input stream filters. $filter->print() works the same
as in output stream filters.
$filter->read() for input stream filters is similar, but
the cumbersome part is that the API requires passing three new arguments
to read(). So currently you do:
while ($filter->read($mode, $block, $readbytes, my $buffer, 1024)) {
$filter->print($buffer);
}
we could avoid passing the first three arguments, that will require
storing them in the filter struct. The drawback of that approach is that
the filter writer (assuming that the streaming interface is used) has no
control over these variables anymore, meaning the read mode. I'm not sure
if it's good. I suppose that if needed we can provide a special API to
modify these attributes, before read is used. So I tend to like the idea
of extending the struct to store these attributes.
again, examples of use can be seen in:
t/filter/TestFilter/in_str_msg.pm
t/filter/TestFilter/in_str_lc.pm
t/filter/TestFilter/in_str_sandwich.pm
t/filter/TestFilter/in_bbs_body.pm
t/filter/TestFilter/in_bbs_msg.pm
t/filter/TestFilter/in_str_consume.pm
---
Finally, other than add/remove filters APIs which we have talked about,
what other APIs do you want for filters?
__
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
