[Chicago-talk] Faking an LDAP server during tests?

[warren at warrenandrachel.com]

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