wstrange / dartdap

DART LDAP Client
BSD 2-Clause "Simplified" License
20 stars 14 forks source link

Tests don't work out-of-the-box #34

Closed hoylen closed 4 years ago

hoylen commented 4 years ago

Warren,

While trying to reproduce a bug, I found the unit tests don't work anymore -- at least not out-of-the-box using an example test OpenLDAP directory server created using the setup script: test/SETUP-dartdap-testing-openldap-centOS7.sh.

Can I revert the first set of changes so they work again with the test directory deployed by the setup script?

What do you want done about the other two?

P.S. The test/SETUP-dartdap-testing-openldap-centOS7.sh setup script still works on CentOS 7.x, but only if you run it with the "--tls-none" option. I'm sure it used to work with "--tls-default" (which is the default when no option is specified), but it no longer does -- but I can think of a fix that might make it work. I have yet to try the "--tls" option (where you provide the private key and certificates to use), but I suspect it is broken too.

Something changed in OpenLDAP and the TLS configuration is no longer accepted. But it is almost impossible to debug, because it seems to always fail and prints out a generic and unhelpful "Other (e.g., implementation specific) error" message.

With CentOS 8, the OpenLDAP server is no longer available from the CentOS repository. So I want to update that setup script to install it from the packages provided by Symas.

wstrange commented 4 years ago

Hi Hoylen Yes, for now please go ahead and revert the configuration changes.

If I ever get time, I'd like to make the tests work with a wider variety of LDAP servers - but for now please dont let this hold you up.

hoylen commented 4 years ago

Ok, I've got most of the tests working again. All except for the one in _query_integrationtest.dart, which expects an LDAP directory "populated with 2000 sample users" according to the comment.

How's this for an idea...

I can update the configuration loading code in test/util.dart to open a config file called "CONFIG.yaml" if it exists. If it does not exist, it will fallback to open a config file called "CONFIG-default.yaml". In the checked-in repository, there will be a "CONFIG-default.yaml" file, but no file called "CONFIG.yaml". That way, out-of-the-box it will use that default file. But the tester can override it.

There can be other config files checked into the repository, for example "CONFIG-opendj.yaml" and "CONFIG-activedirectory.yaml". To use any of those, the tester can create a symlink from "CONFIG.yaml" to one of them. So that will be used instead of the default.

This way, a tester can easily switch between different configurations. But also, the out-of-the-box tester does not have to worry about setting up any configurations (of course they still have to setup their LDAP directory for testing). And any local changes for testing won't affect the checked-in files (which can happen if there was only one config file that was edited by the tester).

The new config files can probably also be simplified by removing the "connections" in the YAML, and just have both sets of settings at the top level.

P.S. If you were wondering, these non-test files start with capitalised names so they are listed separately from the other *-test.dart files. But that depends on the operating system. Alternatively, they could be named something like "00-README.txt" to help make them easier to notice.

wstrange commented 4 years ago

Yea - that sounds fine. Thanks for your help here!