flakm / inmemoryldap

In memory ldap utils to help with integration testing against ldap

GitHub

InMemoryLdap

Build Status Codacy Badge Codacy Badge Maven Central License

Library that helps with in-memory testing against ldap using UnboundID LDAP SDK for Java.

Inspired by embedded-kafka

Version capability

inmemoryldap is available in MavenCentral compiled for scala 2.12 and 2.13. To use add project dependency using the tool of your choice.

sbt

libraryDependencies += "com.github.flakm" %% "inmemoryldap" % version

gradle

compile group: 'com.github.flakm', name: 'inmemoryldap_2.13', version: version

How to use

By default configuration for mock will be taken from reference.conf. Library will look for ldif definitions on classpath by path /ldap/test-data.ldif. Multiple files can be scheduled by manipulating inmemoryldap.files config property. Ldif files will be loaded to server in order of occurrence before running any user code. There are two alternatives of running embedded ldap:

closure style

  import InMemoryLdapServer._
  withRunningLdap { implicit ctx =>
    // ldap will be accessible here on default address: 127.0.0.1:1234
  }
  // before going further all resources will be pruned

start stop style

On the other hand you might want to use your mocked ldap for longer periods of time (ie with trait BeforeAndAfterAll). This style might be easily used with java code. To do so you might use:

    val server: LdapContext = InMemoryLdapServer.start()
    // some code goes here  
    InMemoryLdapServer.stop()

Disabling ssl

By default ldap server will be using ssl. SSL context will be created using trustore and keystores found on classpath in directory /ssl. They are created using create_keys.sh. You might disable ssl for server by setting property inmemoryldap.ssl.enabled = false

Additional settings

Both com.github.flakm.InMemoryLdapServer.start and com.github.flakm.InMemoryLdapServer.withRunningLdapConfig take optional config:

 withRunningLdapConfig(customConfig) { ctx =>
  //code here
 }

You might override those settings by creating your own application.conf under test resources or by using other options described here. For more examples read here or here