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:[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]

Reply via email to