Please provide quick take on several feature requests

[mbaynton]

Hi,
I'd like to ask about how receptive this project might be to these new features:

• Support for ldap_sasl_bind(). I don't think there's a workaround -- getResource() will ldap_bind().
• Add an option to request that the library transparently reconnect, rebind and retry in case of failure. I currently have an issue with my in-house ldap connection handling where if a script binds and then hangs out for awhile, openldap times out the connection. A library like this seems to be the appropriate layer to intercept and deal with server timeouts.
• Define an interface with the core CRUD operations currently implemented in Zend\Ldap\Ldap, and have Zend\Ldap\Ldap implement the interface. This would broaden the possibilities for unit test development, from the point of view of applications that use of this library.

Our in-house codebase is starting to be limited by primitive ldap encapsulation and connection handling. If all these enhancements could be merged in, using your library looks like it could be a good solution for us.

Thanks for your consideration
Mike Baynton

[heiglandreas]

Hi Mike. Thanks for the considerations and also sorry for getting back to you about this so late.

I'll have to check the codebase but I think some of your ideas are very interesting!

Though I'm not sure how an interface for the core CRUD-Operations would broaden the possibilities for unit-testing. Perhaps you could elaborate that a bit further?

Thanks

[mbaynton]

Hi Andreas,
For the CRUD operations interface, I was thinking in terms of registering zend-ldap as a service within your dependency injection framework of choice. With such an interface defined, one could eg. write a lightweight in-memory implementation of the same interface, and plug that "fake ldap" implementation in when running unit tests as a way to achieve a reproducible testing environment.

A problem we currently have is that we've got a large quantity of code that, among other things, changes our ldap. That makes it very hard to test the code as a whole without providing it an actual ldap directory server that starts at a known state at the start of every test. Since zend-ldap already offers a level of abstraction above the ldap_* functions, a natural extension would be to make it easy for zend-ldap users to write mock/fake implementations of the same abstraction.

[heiglandreas]

Hi Mike. You already are able to mock the zend-ldap in your tests without the need for an interface. Using phpunit you could do that like this:

$mock = $this->getMockBuilder(\Zend\Ldap\Ldap::class)->disableOriginalConstructor()->getMock();
$mock->method([methodname you want to call])->…

That already allows you to use zend-ldap in testing without actually invoking anything…

An interface would only make sense when there would be more implementations that implement it. But as Zend-Ldap is the only implementation of - well zend-ldap - there is not really a need for an interface. That would be different should there be different LDAP-Abstraction Layers that agree on one interface they all implement to make the AL interchangeable. But there's currently no such attempt I'm aware of.

[mbaynton]

Andreas,
Sure, but using extensions of classes created on the fly, such as phpunit's getMockBuilder, can become very ugly when the mock has much state or substance. In any case the only impact to zend-ldap would be the addition of an interface file.

[heiglandreas]

Still I'm not understanding where the interface makes it easier to test. You'll need to mock the interface as well. Or, if you want to implement the interface in your own class, you can as well extend Zend\Ldap\Ldap and overwrite the methods you would otherwise implement in your "mock-class".

Though in my experience using the mock-variation for unittests makes it more clear what the tested method is doing and so helps designing the methods more maintainable. Note that that is only valid for unittests. In integration tests that's a completely different story!

In Integration tests I'm usually setting up an LDAP using the setUp and tearDown methods. The LDAP is either running in a virtual machine or is created on the CI-Server. Have a look at the .travis.yml-file or at the .ci-folder how we solved that for zend-ldap

[mbaynton]

On the other points, Support for ldap_sasl_bind() and option to automatically reconnect, are you open to having those in principle?

I think whether you insist on only using mocks generated on the fly vs. using mocks that are regular classes implementing a shared interface is a matter of preference and style, but I'm not the only one that prefers that way. An example that's basically the same idea in a major framework, Symfony has a SessionStorageInterface. When running unit tests against the Symfony framework that depend on sessions, one is encouraged to use MockArraySessionStorage, a conventionally defined class that implements SessionStorageInterface and just stores the session state in memory.

http://symfony.com/doc/current/components/http_foundation/session_testing.html

[mbaynton]

I've written PRs for all these at this point, so this issue asking if they would be welcome can probably be closed.