Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Ladle dishes out steaming helpings of lightweight directory access (LDAP) for use in testing with rspec, cucumber, or any other ruby test framework.
Ruby Java Shell
Branch: master
Failed to load latest commit information.
lib Update for ongoing development.
spec Update to RSpec 3.
support fixed the url because the old one doesn't exist anymore
tasks Remove the bundler-provided tasks that ladle doesn't use.
.ruby-gemset Switch to .ruby-*.
.ruby-version Switch to .ruby-*.
.travis.yml Drop support for Ruby 1.8.7.
.yardopts Document how the custom schema behavior should work.
ASL20-LICENSE Import ApacheDS 1.5.5. Update for ongoing development. Expand, refine, and correct new custom schema docs.
Gemfile open4 is in the gemspec.
LICENSE README, gemspec setup, and other infrastructure.
NOTICE Import ApacheDS 1.5.5. Update for ApacheDS 2.0 & related changes.
Rakefile Add tasks for CI. Bump up tested platforms.
ladle.gemspec Update to RSpec 3.
meta.rakefile Another fix for bundler 1.6.
pom.xml Update java deps for ApacheDS 2.0.0-M16. Add pom file for easy dep up…


Ladle dishes out steaming helpings of lightweight directory access (LDAP) for use in testing with rspec, cucumber, or any other ruby test framework.

It spins up an actual LDAP server instance, so you can use it to test any sort of client application — anything that communicates over the standard LDAP protocol.

Ladle itself is tested on both JRuby 1.7.11 and Ruby 1.9.3, 2.0.0, and 2.1.2. It is a wrapper around ApacheDS (a pure-java embeddable LDAP server), so it needs Java 7 or later available whether you are using JRuby or not.

Ladle will not work with MRI on Windows. (A pull request adding this support would be eagerly reviewed.) It should work with JRuby on Windows, though this hasn't been tested.

Ladle in 30 seconds

To use Ladle, first create a server with some data:

server =
  :port   => 3897,
  :ldif   => "test_users.ldif",
  :domain => "dc=test"

Then start the server:


At this point, you have an LDAP server running on port 3897 with your specified groups and people in it. When you're done with it, just tell it to stop:


Ladle with a test framework

Depending on what you're doing, you might want to run one {Ladle::Server} for all your tests, or have a clean one for each test. Since it takes a few seconds to spin up the server, if you are only reading from the server, it makes sense to use one for all your tests. If you are doing writes, a separate server for each test is safer.

All decent test frameworks can support either mode. Some examples:


To use a server per test, configure and start it in a normal before block, then stop it in an after block:

describe "directory access" do
  before do
    @ldap_server = => true).start

  after do
    @ldap_server.stop if @ldap_server

  it "is possible" do
    # ...

For a shared server, use before(:all) and after(:all) instead. See rspec's docs for more info.


To use a server per test, use Cucumber's Around hook:

Around('@ldap') do |scenario, block|
  ladle = => true).start

If you want just one server, consider something like this:

Before('@ldap') do
  $ladle ||= => true).start

This will start up a server for the first feature which needs it (and has indicated that with the @ldap tag). The server will remain running for all subsequent features and automatically shut down at the end of the run. (Cucumber's hooks documentation notes that you would, in general, need to register an at_exit block for the process to be torn down at the end. {Ladle::Server#start} does this automatically.)

Test data

Ladle accepts data in the standard LDIF format. If you do not specify an LDIF file when creating the server, ladle will use its default data. You can peruse it in lib/ladle/default.ldif.

Note also that you will usually need to provide both the :ldif and :domain configuration parameters. The latter must be the domain component (dc) matching the data in the former. (N.b. the implicit restriction of the data to a single domain.)

Additional classes

If you need to use LDAP classes that are not among the standard set provided by ApacheDS, you'll need to specify a custom schema. See {} for details.

Project links

Non-issue questions can be sent to


Ladle is copyright 2010 Rhett Sutphin. It was built at NUBIC. See the NOTICE file alongside this one for copyright information about software ladle depends on and redistributes.

Something went wrong with that request. Please try again.