Rambla.Handlers.Stub behaviour (Rambla v1.5.0)

View Source

Default handler for Stub testing doubles. Unlike Rambla.Handlers.Mock, this module might be used as a stub for remote service calls when no expectation is to be defined, or when there is no room to define such an expectation (e. g. while application start.)

By default it’d be simply return :ok.

config :rambla, stub: [
  connections: [stubbed: :conn],
  channels: [chan_0: [connection: :stubbed]]
]

# Then you can access the connection/channel via `Rambla.Handlers.Stub` or
#   implicitly via `Rambla` as

Rambla.Handlers.Stub.publish(:chan_0, %{message: %{foo: 42}, serializer: Jason})
Rambla.publish(:chan_0, %{message: %{foo: 42}, serializer: Jason})

Stub modules

To implement the custom Stub, returning any value, or like, use

defmodule ConnStub do
  use Rambla.Handlers.Stub, %{token: "FOOBAR"}

  @behaviour Rambla.Handlers.Stub
  def on_publish(_name, _message, _options) do
    {:ok, @stub_options}
  end
end

Summary

Functions

The list of child_spec returned to be embedded into a supervision tree.

An interface to publish messages using the FSM pool.

The entry point: this would start a supervisor with all the pools and stuff

Callbacks

on_publish(name, message, options)

@callback on_publish(name :: atom(), message :: any(), options :: map()) ::
  Rambla.Handler.resolution()

Functions

children_specs(options \\ [])

The list of child_spec returned to be embedded into a supervision tree.

Known options:

  • connection_options — a keyword() or a function of arity one, which is to receive channel names and return connection options as a list
  • count — the number of workers in the pool
  • child_opts — the options to be passed to the worker’s spec (you won’t need those)

Example

Rambla.Handlers.Redis.children_specs(
  connection_options: [exchange: "amq.direct"], count: 3)

do_handle_publish(stub, name, message, options)

extract_options(payload, map)

publish(id, payload, pid \\ nil)

An interface to publish messages using the FSM pool.

The id is the specific to an implementation, for Amqp it’d be the channel name, for instance.

The second parameter would be a payload, or, if the backend supports it, the function of arity one, which would receive back the connection pid.

Example

Rambla.Handlers.Amqp.publish :channel_name, %{foo: :bar}

start_link(options \\ [])

@spec start_link([
  Supervisor.option()
  | Supervisor.init_option()
  | {:connection_options, keyword() | (term() -> keyword())}
  | {:count, non_neg_integer()}
]) :: Supervisor.on_start()

The entry point: this would start a supervisor with all the pools and stuff