Ruby Hooks Handler for Dredd API Testing Framework

Test your API with the Dredd HTTP API testing framework and write hooks in Ruby!

DISCLAIMER: This is an early version of dred-hooks-ruby, please be aware that it will not be stable until v1.0.0. At any moment, feedback is welcome! : )

Add the gem to your Gemfile:

# Gemfile

gem 'dredd_hooks', '0.1.2' # see semver.org

Create a hook file (the file name is arbitrary):

# ./hooks.rb

require 'dredd_hooks/methods'

include DreddHooks::Methods

before "Machines > Machines collection > Get Machines" do |transaction|
  transaction['skip'] = "true"
end

Run it with Dredd:

# note that the hooks file was named ./hooks.rb
dredd apiary.apib localhost:3000 --language ruby --hookfiles ./hooks.rb

The DreddHooks::Methods module provides the following methods to be used with transaction names:

• before
• after
• before_validation

And these ones to be used without them:

• before_all
• after_all
• before_each
• after_each
• before_each_validation

See also the official Hooks documentation.

Releases are commented to provide a brief change log, details can be found in the CHANGELOG file.

# Run the test suite
rake

A set of RSpec specs provide both a granular documentation and a unit test harness. RSpec tags are used to categorize the spec examples.

Spec examples that are tagged as public describe aspects of the gem public API, and MAY be considered as its documentation.

The private or protected specs are written for development purpose only. Because they describe internal behaviour which may change at any moment without notice, they are only executed as a secondary task by the continuous integration service and SHOULD be ignored.

Run rake spec:public to print the gem public documentation.

A few Cucumber features from the dredd-hooks-template provide an end-to-end test harness. The test suite is provided as a Node.js package and needs to be installed by npm:

npm install

Then the tests can be ran using the npm test command, but for the Ruby paths to be correctly set, an environment variable BUNDLE_GEMFILE needs to be set to the path to the Gemfile. An example how running the end-to-end tests can look like on macOS:

BUNDLE_GEMFILE=$(pwd)/Gemfile npm test

Extending the DSL to support new hooks is meant to be easy, see the maintenance documentation for details. : )

Refactored with love, internet style.

1. Fork it
2. Create your feature branch (git checkout -b my-new-feature)
3. Commit your changes (git commit -am 'Add some feature')
4. Update the CHANGELOG
5. Push to the branch (git push origin my-new-feature)
6. Create a new Pull Request

See LICENSE.