WisperSubscription

This Gem contains a class, WisperSubscription, which encapsulates an extremly simple container to record call parameters for messages, and query methods for whether a defined message was sent. This is a refinement of a class originally developed to record results of very specific Wisper broadcast messages to support testing of broadcasters of such messages. While restructuring that app, the existing BroadcastSuccessTester was identified as a dependency of the testing for multiple to-be-decoupled classes. Including that test-support class in so many redundant places would have been an engraved invitation to sync-related bugs (and egregious waste), and so this WisperSubscription class/Gem was created.

Add this line to your application's Gemfile:

gem 'wisper_subscription'

And then execute:

$ bundle

Or install it yourself as:

$ gem install wisper_subscription

Remember that this was originally developed to support testing Wisper message broadcast from an object. So you might have an RSpec file (Minitest would be similar) that had excerpts similar to:

describe SomeWisperPublishingClass do
  let(:subscriber) { WisperSubscription.new }
  let(:command_params) do
    # ...
  end
  let(:command) { described_class.new command_params }

  before :each do
    # some setup
    subscriber.define_message :success
    subscriber.define_message :failure
    command.subscribe subscriber
    command.do_something_that_broadcasts_a_success
  end

  it 'was successful' do
    payload = subscriber.payload_for(:success, 0)
    expect(payload.first).to be_a WhatYouExpectOnSuccess # as opposed to nil
  end

  # ...
end

You get the idea. If not, open an issue or ask on our Gitter channel.

Parameters: none.

Initialises instance internal state.

Parameters:

1. message (a Symbol; e.g., :bangbang)

Returns: self

Defines a listener method (e.g., #bangbang) to receive events published by a Wisper publisher or similar mechaism. Any parameters a listener method is called with will be retreivaable by using the #payload_for or #payloads_for methods (see below).

Defines a query method (e.g., #bangbang?) which returns true if payloads for the message have been received; false otherwise.

Parameters:

1. message (a Symbol, e.g., :bangbang)

Returns: an Array

Returns an Array of all payloads received by the listener method corresponding to the parameter. If no calls to the listener method have been made, or if the listener method has not been defined because #define_message has not been called using that message, then an empty Array is returned.

Parameters:

1. message (a Symbol, e.g., :bangbang)
2. index (an integer, defaulting to 0)

Returns: an Array or nil

Returns an Array containing the payload received by the indexth invocation of the listener method (zero-based). A payload is simply the set of (zero or) more) parameters sent to the listener method. If no calls to the listener method have been made, or if the listener method has not been defined because #define_message has not been called using that message, then this method returns nil. If the listener method has been defined but the specified index is outside the range of received payloads, then returns an empty Array.

1. Fork it ( https://github.com/jdickey/wisper_subscription/fork )
2. Create your feature branch (git checkout -b my-new-feature)
3. Ensure that your changes are completely covered by passing specs, and comply with the Ruby Style Guide as enforced by RuboCop. To verify this, run bundle exec rake, noting and repairing any lapses in coverage or style violations;
4. Commit your changes (git commit -a). Please do not use a single-line commit message (git commit -am "some message"). A good commit message notes what was changed and why in sufficient detail that a relative newcomer to the code can understand your reasoning and your code;
5. Push to the branch (git push origin my-new-feature)
6. Create a new Pull Request. Describe at some length the rationale for your new feature; your implementation strategy at a higher level than each individual commit message; anything future maintainers should be aware of; and so on. If this is a modification to existing code, reference the open issue being addressed.
7. Don't be discouraged if the PR generates a discussion that leads to further refinement of your PR through additional commits. These should generally be discussed in comments on the PR itself; discussion in the Gitter room (see below) may also be useful;
8. If you've comments, questions, or just want to talk through your ideas, come hang out in the project's room on Gitter. Ask away!