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.
- Fork it
- Create your feature branch (
git checkout -b my-new-feature
) - Commit your changes (
git commit -am 'Add some feature'
) - Update the
CHANGELOG
- Push to the branch (
git push origin my-new-feature
) - Create a new Pull Request
See LICENSE
.