Have you thought of connecting to a real LDAP server and doing your
queries, then using Storable or Data::Dumper to store the results of
these? That would greatly simplify your needs if all you had to do was
create a hash lookup that bound LDAP queries to result sets.
> Thanks for this. What I realized from reading this is that I don't
> actually need to load my module into Apache to test its functionality.
> I can call the handler as though it were a regular subroutine.
>> However, this opens up the new problem of faking the Apache->request
> object. I think if I manipulate @INC to look for modules (first) in
> "t/" while the tests are running, I can write fake versions of Apache
> and Net::LDAP that will automagically load and suit my needs.
>> This isn't optimal, though, because I don't want to introduce bugs in my
> tests by not doing a good enough job of faking Net::LDAP and Apache::*.
>> I think I will need to research this further and write a
> Test::Apache::MockObject. There should be a way to inject code into
> modules loaded into Apache by loading another module to manipulate the
> symbol table at the right moment.
>> Unfortunately I'm kind of busy until after YAPC, so this will have to
> wait. In the mean time, please feel free to provide additional
> suggestions :)
>> Regards,
> Jonathan Rockway
>> Steven Lembark wrote:
>>>> -- Jonathan Rockway <jon at jrock.us>
>>>>> Anyway, any insight would be appreciated.
>>>> Perl Testing Programmer's Notebook from O'Reilly
>> (blue job with the pre-printed coffee stains).
>>>> Extreme summary: Write a "fake" module that returns
>> success/failure for a specific set of calls or a
>> specific set of data for them. Call that class and
>> record whether your client code properly recognizes
>> the exceptions, returns, and failures. No reason you
>> can't embed the fake class into your .t code.
>>>> Once you have tested whether your code can deal with
>> failures and baseline call syntax appropriately there
>> really isn't more you can do without a "real" server.
>>>> Sub::AutoStub does some of this for you easily by
>> allowing the methods to return a fixed value via
>> AUTOLOAD (i.e., saves you from having to hack out
>> and maintain a bunch of stubs just for the one test).
>>> _______________________________________________
> Chicago-talk mailing list
>Chicago-talk at pm.org>http://mail.pm.org/mailman/listinfo/chicago-talk