You are viewing a plain text version of this content. The canonical link for it is here.
Posted to test-dev@httpd.apache.org by William McKee <wi...@knowmad.com> on 2004/03/03 20:16:12 UTC

A::T and paths

Hi Stas,

The new version of A::T is giving me some odd behavior in regards to
paths. Hopefully you can clear it up for me.

I have 3 response tests which import data from an external file via a
require statement like so:

    require 'data/userdata.pl';

When run independently, each of these scripts work fine. However, if I
try to run all 3 simultaneously, the first one works and gets the data
then the following two fail to load. I've added code to output the cwd
and in all cases it is returning '/'. If I add t/ to the require
statement, I get errors. I'm not sure how to tell A::T to look into the
data directory in the t/ directory and didn't see any docs about how
A::T is handling paths with the recent updates.

I'm using the following line to check that the data was properly read
from the file:

  plan $r, tests => 9, have { "Unable to load \$userdata." => defined
    $userdata && ref $userdata eq 'HASH' };

I've tried switching the order these files run and I get the same
results. One weird thing I'm seeing is that the 3rd response test is
outputting a concatenated list of the have() tests as shown below:

admin/load_mail.......skipped
        all skipped: Unable to load $userdata., Unable to load $userdata.

When I switched the order of the tests, this concatenation did not
happen (this load_mail test was still skipped but with only a single
error message).

I suspect that I'm doing something wrong or unexpected. If necessary, I
can try to replicate this behavior in a test script.


Thanks again,
William

-- 
Knowmad Services Inc.
http://www.knowmad.com

Re: A::T and paths

Posted by William McKee <wi...@knowmad.com>.
On Wed, Mar 03, 2004 at 11:49:54AM -0800, Stas Bekman wrote:
> Sounds like it's unrelated to A-T, where do you load those from? Server 
> side or the client side? Is it the same name? If the server side and the 
> same name then you hit the famous problem:

Yep, it was the famous problem; Scenario 3 to be precise! Thanks for the
quick response.


William

-- 
Knowmad Services Inc.
http://www.knowmad.com

Re: A::T and paths

Posted by Stas Bekman <st...@stason.org>.
William McKee wrote:
> Hi Stas,
> 
> The new version of A::T is giving me some odd behavior in regards to
> paths. Hopefully you can clear it up for me.
> 
> I have 3 response tests which import data from an external file via a
> require statement like so:
> 
>     require 'data/userdata.pl';
> 
> When run independently, each of these scripts work fine. However, if I
> try to run all 3 simultaneously, the first one works and gets the data
> then the following two fail to load. I've added code to output the cwd
> and in all cases it is returning '/'. If I add t/ to the require
> statement, I get errors. I'm not sure how to tell A::T to look into the
> data directory in the t/ directory and didn't see any docs about how
> A::T is handling paths with the recent updates.
> 
> I'm using the following line to check that the data was properly read
> from the file:
> 
>   plan $r, tests => 9, have { "Unable to load \$userdata." => defined
>     $userdata && ref $userdata eq 'HASH' };
> 
> I've tried switching the order these files run and I get the same
> results. One weird thing I'm seeing is that the 3rd response test is
> outputting a concatenated list of the have() tests as shown below:
> 
> admin/load_mail.......skipped
>         all skipped: Unable to load $userdata., Unable to load $userdata.
> 
> When I switched the order of the tests, this concatenation did not
> happen (this load_mail test was still skipped but with only a single
> error message).
> 
> I suspect that I'm doing something wrong or unexpected. If necessary, I
> can try to replicate this behavior in a test script.

Sounds like it's unrelated to A-T, where do you load those from? Server side 
or the client side? Is it the same name? If the server side and the same name 
  then you hit the famous problem:
http://perl.apache.org/docs/1.0/guide/porting.html#Name_collisions_with_Modules_and_libs


__________________________________________________________________
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