rspec-fire-roles 0.1

data/.gitignore

@@ -0,0 +1,17 @@
+*.gem
+*.rbc
+.bundle
+.config
+.yardoc
+Gemfile.lock
+InstalledFiles
+_yardoc
+coverage
+doc/
+lib/bundler/man
+pkg
+rdoc
+spec/reports
+test/tmp
+test/version_tmp
+tmp

data/Gemfile

@@ -0,0 +1,4 @@
+source "https://rubygems.org"
+
+# Specify your gem's dependencies in rspec-fire-roles.gemspec
+gemspec

data/LICENSE.txt

@@ -0,0 +1,22 @@
+Copyright (c) 2013 Chris Vincent
+
+MIT License
+
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of this software and associated documentation files (the
+"Software"), to deal in the Software without restriction, including
+without limitation the rights to use, copy, modify, merge, publish,
+distribute, sublicense, and/or sell copies of the Software, and to
+permit persons to whom the Software is furnished to do so, subject to
+the following conditions:
+
+The above copyright notice and this permission notice shall be
+included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
+LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

data/README.md

@@ -0,0 +1,164 @@
+# rspec-fire-roles
+
+Mocking against roles rather than concrete objects results in more flexible,
+pluggable object designs. This gem builds upon the capabilities of rspec-fire
+to make it easier to mock in this style while also knowing with confidence that
+your objects and their collaborators are speaking through the same interfaces.
+
+## Installation
+
+Add this line to your application's Gemfile:
+
+    gem "rspec-fire-roles"
+
+Or install it yourself with:
+
+    $ gem install rspec-fire-roles
+
+Add it to your `spec_helper.rb`:
+
+    RSpec.configure do |config|
+      config.include RSpec::Fire
+      config.include RSpec::Fire::Roles
+    end
+
+## Why
+
+While rspec-fire allows you to create mocks of specific concrete classes, this
+isn't quite enough if you'd like to mock a *role* rather than a class. Mocking
+roles results in more flexible designs, because a given object might play more
+than one role, and more than one object might play the same role. Thinking in
+terms of roles rather than objects also assists in the process of *interface
+discovery*, which is the main purpose of behavior-driven development as an
+assistant to the design process.
+
+For more on the topic of mocking roles, see [the seminal paper on the
+topic](http://jmock.org/oopsla2004.pdf). Also highly recommended reads are the
+infamous [Growing Object-Oriented Software Guided by
+Tests](http://amzn.to/VWOwyA) and [Practical Object-Oriented Design in
+Ruby](http://amzn.to/VWOHtP). See also the example usage below.
+
+*Full disclosure: Them be affiliate links.*
+
+## Usage
+
+Skip directly to the [Relish
+documentation](https://www.relishapp.com/cvincent/rspec-fire-roles/docs/using-roles-with-rspec-fire)
+for a simple worked example. Read on for a more detailed explanation.
+
+Let's say you have a `BatchSender` object. Here's your spec:
+
+    require "roles/notifier"
+
+    describe BatchSender do
+      describe "#send_messages" do
+        it "passes each message to the injected notifier" do
+          notifier = fire_double("Roles::Notifier")
+          instance = BatchSender.new(notifier)
+          notifier.should_receive(:notify).with("Subject 1", "Body 1").once
+          notifier.should_receive(:notify).with("Subject 2").once
+
+          instance.send_messages([["Subject 1", "Body 1"], ["Subject 2"]])
+        end
+      end
+    end
+
+We're using a regular old `fire_double` here to create the mock, just like with
+rspec-fire. But notice that, rather than passing in the name of some concrete
+class which implements `#notify` with two arguments, we pass in the name of a
+role. Here's that role, defined in `spec/roles/notifier.rb` (though it can be
+defined anywhere as long as it gets included), which should be required in any
+isolated unit test which depends upon this role so that rspec-fire recognizes
+it:
+
+    module Roles
+      class Notifier
+        def notify(subject, body = nil)
+        end
+      end
+    end
+
+It's just an empty implementation of the interface. Thanks to rspec-fire, our
+specs will now fail if they depend upon the `Notifier` role but the mock
+expectations don't match this interface.
+
+Now here's where rspec-fire-roles comes in.  Here's the spec for a concrete
+object which implements the `Notifier` role:
+
+    require "roles/notifier"
+
+    describe EmailNotifier do
+      implements_role "Roles::Notifier"
+
+      # [...] class-specific specs about notifying via email, not shown
+    end
+
+The `implements_role` macro ensures that this spec will fail if the
+`EmailNotifier` class doesn't have the right methods to satisfy the `Notifier`
+role. Of course, this class can have additional public methods which don't have
+anything to do with the role; the macro only checks that the methods on
+`Notifier` are also implemented on `EmailNotifier`. Furthermore, multiple
+`implements_role` calls can be added to the spec for objects which play more
+than one role.
+
+Here's an example of another class in the same system which plays this role,
+plus another role (for demonstration purposes):
+
+    require "roles/notifier"
+
+    describe SmsNotifier do
+      implements_role "Roles::Notifier"
+      implements_role "Roles::Serializable"
+
+      # [...] class-specific specs about notifying via SMS, not shown
+    end
+
+You should be able to see what this gains over using rspec-fire alone. Let's
+say later you decide to extract a Value Object instead of using arrays to
+represent messages. First you change the role:
+
+    module Roles
+      class Notifier
+        def notify(message)
+        end
+      end
+    end
+
+Now your `BatchSender` spec will fail because the `fire_double` is expecting
+the wrong arguments, and your specs for `EmailNotifier` and `SmsNotifier` will
+fail because the classes still implement the old interface which takes a
+subject and body. You you can haz fast, isolated unit tests which mock roles
+rather than objects without having to worry or write extra integration tests to
+ensure that the objects play well together. Bliss!
+
+## Future improvements
+
+ * It would be cool to have a nicer DSL for defining roles than just empty
+   implementations.
+ * It would also be cool if roles defined default return values for their
+   `fire_double`s.
+ * The `implements_role` method presently only supports the interface of
+   instances of the class. It would be nice to be able to specify that a role
+   is implemented by class methods instead.
+ * False positives are still possible. If expectations on a `fire_double` are
+   set with the correct number arguments, but the types of the arguments are
+   incorrect (for example, the role expects a single float parameter but a
+   string is passed in), there's no way to detect this disparity because
+   arguments aren't typed. I can imagine placing additional constraints a role
+   such that arguments must match some other role, though I don't know if such
+   a restriction would be worth it. In practice, such a scenario is probably
+   quite rare.
+ * The way rspec-fire works, there is no failure in a dependent class's spec if
+   the role is simply not defined. This is intentional so that using
+   `fire_double`s can be done in both isolation and integration. Be sure your
+   roles are actually being required when you use them, which should be fast
+   enough for isolated tests.
+ * Anything else. Feedback is appreciated!
+
+## Contributing
+
+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. Push to the branch (`git push origin my-new-feature`)
+5. Create new Pull Request

data/Rakefile

@@ -0,0 +1,3 @@
+require "bundler/gem_tasks"
+require "cucumber/rake/task"
+Cucumber::Rake::Task.new(:features)

data/features/readme.md

@@ -0,0 +1,164 @@
+# rspec-fire-roles
+
+Mocking against roles rather than concrete objects results in more flexible,
+pluggable object designs. This gem builds upon the capabilities of rspec-fire
+to make it easier to mock in this style while also knowing with confidence that
+your objects and their collaborators are speaking through the same interfaces.
+
+## Installation
+
+Add this line to your application's Gemfile:
+
+    gem "rspec-fire-roles"
+
+Or install it yourself with:
+
+    $ gem install rspec-fire-roles
+
+Add it to your `spec_helper.rb`:
+
+    RSpec.configure do |config|
+      config.include RSpec::Fire
+      config.include RSpec::Fire::Roles
+    end
+
+## Why
+
+While rspec-fire allows you to create mocks of specific concrete classes, this
+isn't quite enough if you'd like to mock a *role* rather than a class. Mocking
+roles results in more flexible designs, because a given object might play more
+than one role, and more than one object might play the same role. Thinking in
+terms of roles rather than objects also assists in the process of *interface
+discovery*, which is the main purpose of behavior-driven development as an
+assistant to the design process.
+
+For more on the topic of mocking roles, see [the seminal paper on the
+topic](http://jmock.org/oopsla2004.pdf). Also highly recommended reads are the
+infamous [Growing Object-Oriented Software Guided by
+Tests](http://amzn.to/VWOwyA) and [Practical Object-Oriented Design in
+Ruby](http://amzn.to/VWOHtP). See also the example usage below.
+
+*Full disclosure: Them be affiliate links.*
+
+## Usage
+
+Skip directly to the [Relish
+documentation](https://www.relishapp.com/cvincent/rspec-fire-roles/docs/using-roles-with-rspec-fire)
+for a simple worked example. Read on for a more detailed explanation.
+
+Let's say you have a `BatchSender` object. Here's your spec:
+
+    require "roles/notifier"
+
+    describe BatchSender do
+      describe "#send_messages" do
+        it "passes each message to the injected notifier" do
+          notifier = fire_double("Roles::Notifier")
+          instance = BatchSender.new(notifier)
+          notifier.should_receive(:notify).with("Subject 1", "Body 1").once
+          notifier.should_receive(:notify).with("Subject 2").once
+
+          instance.send_messages([["Subject 1", "Body 1"], ["Subject 2"]])
+        end
+      end
+    end
+
+We're using a regular old `fire_double` here to create the mock, just like with
+rspec-fire. But notice that, rather than passing in the name of some concrete
+class which implements `#notify` with two arguments, we pass in the name of a
+role. Here's that role, defined in `spec/roles/notifier.rb` (though it can be
+defined anywhere as long as it gets included), which should be required in any
+isolated unit test which depends upon this role so that rspec-fire recognizes
+it:
+
+    module Roles
+      class Notifier
+        def notify(subject, body = nil)
+        end
+      end
+    end
+
+It's just an empty implementation of the interface. Thanks to rspec-fire, our
+specs will now fail if they depend upon the `Notifier` role but the mock
+expectations don't match this interface.
+
+Now here's where rspec-fire-roles comes in.  Here's the spec for a concrete
+object which implements the `Notifier` role:
+
+    require "roles/notifier"
+
+    describe EmailNotifier do
+      implements_role "Roles::Notifier"
+
+      # [...] class-specific specs about notifying via email, not shown
+    end
+
+The `implements_role` macro ensures that this spec will fail if the
+`EmailNotifier` class doesn't have the right methods to satisfy the `Notifier`
+role. Of course, this class can have additional public methods which don't have
+anything to do with the role; the macro only checks that the methods on
+`Notifier` are also implemented on `EmailNotifier`. Furthermore, multiple
+`implements_role` calls can be added to the spec for objects which play more
+than one role.
+
+Here's an example of another class in the same system which plays this role,
+plus another role (for demonstration purposes):
+
+    require "roles/notifier"
+
+    describe SmsNotifier do
+      implements_role "Roles::Notifier"
+      implements_role "Roles::Serializable"
+
+      # [...] class-specific specs about notifying via SMS, not shown
+    end
+
+You should be able to see what this gains over using rspec-fire alone. Let's
+say later you decide to extract a Value Object instead of using arrays to
+represent messages. First you change the role:
+
+    module Roles
+      class Notifier
+        def notify(message)
+        end
+      end
+    end
+
+Now your `BatchSender` spec will fail because the `fire_double` is expecting
+the wrong arguments, and your specs for `EmailNotifier` and `SmsNotifier` will
+fail because the classes still implement the old interface which takes a
+subject and body. You you can haz fast, isolated unit tests which mock roles
+rather than objects without having to worry or write extra integration tests to
+ensure that the objects play well together. Bliss!
+
+## Future improvements
+
+ * It would be cool to have a nicer DSL for defining roles than just empty
+   implementations.
+ * It would also be cool if roles defined default return values for their
+   `fire_double`s.
+ * The `implements_role` method presently only supports the interface of
+   instances of the class. It would be nice to be able to specify that a role
+   is implemented by class methods instead.
+ * False positives are still possible. If expectations on a `fire_double` are
+   set with the correct number arguments, but the types of the arguments are
+   incorrect (for example, the role expects a single float parameter but a
+   string is passed in), there's no way to detect this disparity because
+   arguments aren't typed. I can imagine placing additional constraints a role
+   such that arguments must match some other role, though I don't know if such
+   a restriction would be worth it. In practice, such a scenario is probably
+   quite rare.
+ * The way rspec-fire works, there is no failure in a dependent class's spec if
+   the role is simply not defined. This is intentional so that using
+   `fire_double`s can be done in both isolation and integration. Be sure your
+   roles are actually being required when you use them, which should be fast
+   enough for isolated tests.
+ * Anything else. Feedback is appreciated!
+
+## Contributing
+
+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. Push to the branch (`git push origin my-new-feature`)
+5. Create new Pull Request

data/features/rspec_fire_roles.feature

@@ -0,0 +1,112 @@
+Feature: Using roles with rspec-fire
+  In order to mock roles rather than objects and build more flexible systems
+  As an avid RSpec user
+  I want to see failing specs when role interfaces are not honored
+
+  Background:
+    Given a file named "spec_helper.rb" with:
+      """ruby
+      require "rubygems"
+      require "bundler/setup"
+      Bundler.setup
+
+      require "rspec/fire"
+      require "rspec/fire/roles"
+
+      RSpec.configure do |config|
+        config.include RSpec::Fire
+        config.include RSpec::Fire::Roles
+      end
+      """
+    And a file named "batch_sender_spec.rb" with:
+      """ruby
+      require "spec_helper"
+      require "batch_sender"
+      require "notifier"
+
+      describe BatchSender do
+        describe "#send_messages" do
+          it "passes each message to the injected notifier" do
+            notifier = fire_double("Roles::Notifier")
+            instance = BatchSender.new(notifier)
+            notifier.should_receive(:notify).with("Subject 1", "Body 1").once
+            notifier.should_receive(:notify).with("Subject 2").once
+
+            instance.send_messages([["Subject 1", "Body 1"], ["Subject 2"]])
+          end
+        end
+      end
+      """
+    And a file named "batch_sender.rb" with:
+      """ruby
+      class BatchSender
+        def initialize(notifier)
+          @notifier = notifier
+        end
+
+        def send_messages(messages)
+          messages.each { |msg| @notifier.notify(*msg.compact) }
+        end
+      end
+      """
+    And a file named "notifier.rb" with:
+      """ruby
+      module Roles
+        class Notifier
+          def notify(subject, body = nil); end
+        end
+      end
+      """
+    And a file named "email_notifier_spec.rb" with:
+      """ruby
+      require "spec_helper"
+      require "email_notifier"
+      require "notifier"
+
+      describe EmailNotifier do
+        implements_role "Roles::Notifier"
+      end
+      """
+
+  Scenario: A role with a matching implementation
+    Given a file named "email_notifier.rb" with:
+      """ruby
+      class EmailNotifier
+        def notify(subject, body = nil); end
+      end
+      """
+    When I run `rspec batch_sender_spec.rb email_notifier_spec.rb`
+    Then it should pass
+
+  Scenario: A role with a method with the wrong arguments defined
+    Given a file named "email_notifier.rb" with:
+      """ruby
+      class EmailNotifier
+        def notify(message); end
+      end
+      """
+    When I run `rspec batch_sender_spec.rb`
+    Then it should pass
+    When I run `rspec email_notifier_spec.rb`
+    Then it should fail with "Incomplete implementation of Roles::Notifier. Parameters for #notify(subject, body = nil) do not match."
+
+  Scenario: A role with an implementation missing a method
+    Given a file named "email_notifier.rb" with:
+      """ruby
+      class EmailNotifier
+      end
+      """
+    When I run `rspec batch_sender_spec.rb`
+    Then it should pass
+    When I run `rspec email_notifier_spec.rb`
+    Then it should fail with "Incomplete implementation of Roles::Notifier. #notify(subject, body = nil) is not defined."
+
+  Scenario: A role with an implementation with incorrectly-named arguments
+    Given a file named "email_notifier.rb" with:
+      """ruby
+      class EmailNotifier
+        def notify(name, content = nil); end
+      end
+      """
+    When I run `rspec batch_sender_spec.rb email_notifier_spec.rb`
+    Then it should fail with "Incomplete implementation of Roles::Notifier. Parameters for #notify(subject, body = nil) do not match."

data/features/step_definitions/rspec_steps.rb

@@ -0,0 +1,8 @@
+Then /it should fail with "(.+)"/ do |message|
+  step "the exit status should be 1"
+  step %{the output should contain "#{message}"}
+end
+
+Then "it should pass" do
+  step "the exit status should be 0"
+end

data/features/support/env.rb

@@ -0,0 +1,13 @@
+require "rubygems"
+require "bundler"
+Bundler.setup
+
+require "aruba/cucumber"
+
+Before do
+  load_paths, requires = ["../../lib"], []
+  load_paths.push($LOAD_PATH.grep %r|bundler/gems|)
+  load_paths << "."
+
+  set_env('RUBYOPT', "-I#{load_paths.join(':')}")
+end

data/lib/rspec/fire/roles.rb

@@ -0,0 +1,44 @@
+require "rspec/fire/roles/version"
+
+module RSpec
+  module Fire
+    module Roles
+      def self.included(base)
+        base.extend(ClassMethods)
+      end
+
+      protected
+
+      def incomplete_implementation(role, error)
+        fail "Incomplete implementation of #{role}. #{error}"
+      end
+
+      module ClassMethods
+        def implements_role(role)
+          role = role.split("::").inject(Kernel) { |last, const| last.const_get(const) }
+
+          describe "#{role} interface" do
+            role.public_instance_methods(false).each do |m|
+              m = role.public_instance_method(m)
+              params = m.parameters.map { |(opt, name)| name.to_s + (opt == :opt ? " = nil" : "") }.join(", ")
+
+              it "defines ##{m.name}(#{params})" do
+                begin
+                  klass = subject.class
+                  imp = klass.public_instance_method(m.name.to_sym)
+
+                  if imp.parameters != m.parameters
+                    incomplete_implementation(role, "Parameters for ##{m.name}(#{params}) do not match.")
+                  end
+                rescue NameError
+                  puts $!.inspect
+                  incomplete_implementation(role, "##{m.name}(#{params}) is not defined.")
+                end
+              end
+            end
+          end
+        end
+      end
+    end
+  end
+end

data/lib/rspec/fire/roles/version.rb

@@ -0,0 +1,7 @@
+module RSpec
+  module Fire
+    module Roles
+      VERSION = "0.1"
+    end
+  end
+end

data/rspec-fire-roles.gemspec

@@ -0,0 +1,24 @@
+# encoding: utf-8
+lib = File.expand_path("../lib", __FILE__)
+$LOAD_PATH.unshift(lib) unless $LOAD_PATH.include?(lib)
+require "rspec/fire/roles/version"
+
+Gem::Specification.new do |gem|
+  gem.name          = "rspec-fire-roles"
+  gem.version       = RSpec::Fire::Roles::VERSION
+  gem.authors       = ["Chris Vincent"]
+  gem.email         = ["c.j.vincent@gmail.com"]
+  gem.description   = %q{Mock roles, not objects. For use with rspec-fire.}
+  gem.summary       = gem.description
+  gem.homepage      = "http://github.com/cvincent/rspec-fire-roles"
+
+  gem.files         = `git ls-files`.split($/)
+  gem.executables   = gem.files.grep(%r{^bin/}).map{ |f| File.basename(f) }
+  gem.test_files    = gem.files.grep(%r{^(test|spec|features)/})
+  gem.require_paths = ["lib"]
+
+  gem.add_development_dependency "cucumber", "~> 1.2"
+  gem.add_development_dependency "aruba", "~> 0.5"
+
+  gem.add_dependency "rspec-fire", "~> 1.1"
+end

metadata

@@ -0,0 +1,94 @@
+--- !ruby/object:Gem::Specification
+name: rspec-fire-roles
+version: !ruby/object:Gem::Version
+  version: '0.1'
+  prerelease: 
+platform: ruby
+authors:
+- Chris Vincent
+autorequire: 
+bindir: bin
+cert_chain: []
+date: 2013-02-25 00:00:00.000000000 Z
+dependencies:
+- !ruby/object:Gem::Dependency
+  name: cucumber
+  requirement: &2177347760 !ruby/object:Gem::Requirement
+    none: false
+    requirements:
+    - - ~>
+      - !ruby/object:Gem::Version
+        version: '1.2'
+  type: :development
+  prerelease: false
+  version_requirements: *2177347760
+- !ruby/object:Gem::Dependency
+  name: aruba
+  requirement: &2177347260 !ruby/object:Gem::Requirement
+    none: false
+    requirements:
+    - - ~>
+      - !ruby/object:Gem::Version
+        version: '0.5'
+  type: :development
+  prerelease: false
+  version_requirements: *2177347260
+- !ruby/object:Gem::Dependency
+  name: rspec-fire
+  requirement: &2177346800 !ruby/object:Gem::Requirement
+    none: false
+    requirements:
+    - - ~>
+      - !ruby/object:Gem::Version
+        version: '1.1'
+  type: :runtime
+  prerelease: false
+  version_requirements: *2177346800
+description: Mock roles, not objects. For use with rspec-fire.
+email:
+- c.j.vincent@gmail.com
+executables: []
+extensions: []
+extra_rdoc_files: []
+files:
+- .gitignore
+- Gemfile
+- LICENSE.txt
+- README.md
+- Rakefile
+- features/readme.md
+- features/rspec_fire_roles.feature
+- features/step_definitions/rspec_steps.rb
+- features/support/env.rb
+- lib/rspec/fire/roles.rb
+- lib/rspec/fire/roles/version.rb
+- rspec-fire-roles.gemspec
+homepage: http://github.com/cvincent/rspec-fire-roles
+licenses: []
+post_install_message: 
+rdoc_options: []
+require_paths:
+- lib
+required_ruby_version: !ruby/object:Gem::Requirement
+  none: false
+  requirements:
+  - - ! '>='
+    - !ruby/object:Gem::Version
+      version: '0'
+required_rubygems_version: !ruby/object:Gem::Requirement
+  none: false
+  requirements:
+  - - ! '>='
+    - !ruby/object:Gem::Version
+      version: '0'
+requirements: []
+rubyforge_project: 
+rubygems_version: 1.8.16
+signing_key: 
+specification_version: 3
+summary: Mock roles, not objects. For use with rspec-fire.
+test_files:
+- features/readme.md
+- features/rspec_fire_roles.feature
+- features/step_definitions/rspec_steps.rb
+- features/support/env.rb