No commit activity in last 3 years
No release in over 3 years
There's a lot of open issues
Interactors are a pattern for structuring your business logic into units. They have a flexible context that they pass between them, which makes them easy-to-write, but hard-to-understand after you've written them. Much of this confusion comes from not knowing what the interactor is supposed to take as input and what it's expected to produce. Enter contracts. Contracts allow you define, up front, a contract both for the input of an interactor, known as expectations, and the output of it, known as promises. Additionally, you can define a handler for what happens when an interactor violates its contracts, known as a breach. Declaring these contracts can help define your interface and make it easier to understand how to use an interactor. They form both documentation and validation for your business logic.


> 1.11


 Project Readme


Build Status Code Climate Inline docs

Interactor::Contracts is an extension to the interactor gem that gives you the ability to specify the expectations (expected inputs) and promises (expected outputs) of your interactors.


Add this line to your application's Gemfile:

gem 'interactor-contracts'

And then execute:

$ bundle

Or install it yourself as:

$ gem install interactor-contracts


Let's extend the sample AuthenticateUser from the Interactor examples with a contract that specifies its expectations and promises.

class AuthenticateUser
  include Interactor
  include Interactor::Contracts

  expects do

  promises do

  on_breach do |breaches|!(breaches)

  def call
    if user = User.authenticate(, context.password)
      context.user = user
      context.token = user.secret_token
    else!(:message => "authenticate_user.failure")

Inputs: expectations

The expects block defines the expectations: the expected attributes of the context prior to the interactor running, along with any predicates that further constrain the input.

Outputs: promises

The promises block defines the promises: the expected attributes of the context after the interactor runs and successfully completes, along with any predicates the further constrain the output. Note, for backward-compatibility, this is also available via the assures method.

Because interactors can have transitive dependencies through the use of organizers, any other inputs or outputs are ignored from the perspective of the contract and are passed along to the outgoing (successful) context.

Both expects and promises wrap dry-validation, so you can use any predicates defined in it to describe the expected inputs and outputs of your interactor.

Contract failures: breaches

By default, contract failures, or breaches, behave like the example above: breached keys are set on the failed context with their contract failures as values. Note that you do not have to define an on_breach for the behavior, but if you do this behavior will not occur.

If there are more complicated things you wish to do with contract failures, you can define one or more breach handlers.

To hook into a failed expectation or promise, you can use the on_breach method to defined a breach handler. It should take a 1-arity block that expects an array of Breach objects. These objects have a property attribute that will give you the key that's in breach of its contract. Breaches also have a messages attribute that gives the reasons that property is in breach.

By default, when an on_breach consequence is not specified, the contract will #fail! the Interactor::Context with the keys that are in breach and arrays of messages about what the breaches are.

For example, the above interactor acts as follows:

result ={})
#=> #<Interactor::Context email=["email is missing"], password=["password is missing"]>

result.failure?  #=> true

If you would rather have your contract breaches be aggregated into, for example, an errors property, you could use a breach handler like the following:

on_breach do |breaches|!(errors: breaches)

I18n support

You can configure the underlying dry-validation contract by passing a block to the config method in your contract. This block will be evaluated on the underlying configuration for the contract. For example, if you want to set up the contract to use I18n in your Rails app, you might do something like this:

class MyInteractor
  include Interactor
  include Interactor::Contracts

  config do
    messages.backend = :i18n
    messages.load_paths << Rails.root / 'config' / 'locales' / 'errors.yml'
    messages.top_namespace = :interactor_contracts

This sets up the I18n system (assuming the delicate load-order has been done in the right way - you have to require i18n prior to requiring interactor-contracts since we load dry-validation immediately) to use your custom file. All lookups for error messages happen starting at the interactor_contracts key in this example.

See the documentation for dry-validation for more information.


After checking out the repo, run bin/setup to install dependencies. Then, run rake spec to run the tests. You can also run bin/console for an interactive prompt that will allow you to experiment.

When writing code, you can use the helper application Guard to automatically run tests and coverage tools whenever you modify and save a file. This helps to eliminate the tedium of running tests manually and reduces the change that you will accidentally forget to run the tests. To use Guard, run bundle exec guard.

Before committing code, run rake to check that the code conforms to the style guidelines of the project, that all of the tests are green (if you're writing a feature; if you're only submitting a failing test, then it does not have to pass!), and that the changes are sufficiently documented.

To install this gem onto your local machine, run bundle exec rake install. To release a new version, update the version number in version.rb, and then run bundle exec rake release, which will create a git tag for the version, push git commits and tags, and push the .gem file to


Bug reports and pull requests are welcome on GitHub at

Supported Ruby Versions

This library aims to support and is tested against the following Ruby versions:

  • Ruby 2.4
  • Ruby 2.5
  • Ruby 2.6
  • JRuby 9.2

If something doesn't work on one of these versions, it's a bug.

This library may inadvertently work (or seem to work) on other Ruby versions, however support will only be provided for the versions listed above.

If you would like this library to support another Ruby version or implementation, you may volunteer to be a maintainer. Being a maintainer entails making sure all tests run and pass on that implementation. When something breaks on your implementation, you will be responsible for providing patches in a timely fashion. If critical issues for a particular implementation exist at the time of a major release, support for that Ruby version may be dropped.


This library aims to adhere to Semantic Versioning 2.0.0. Violations of this scheme should be reported as bugs. Specifically, if a minor or patch version is released that breaks backward compatibility, that version should be immediately yanked and/or a new version should be immediately released that restores compatibility. Breaking changes to the public API will only be introduced with new major versions. As a result of this policy, you can (and should) specify a dependency on this gem using the Pessimistic Version Constraint with two digits of precision. For example:

spec.add_dependency "interactor-contracts", "~> 0.1"


The gem is available as open source under the terms of the MIT License.