OlegIlyenko

import sangria.schema._
import sangria.execution._
import sangria.macros._
import sangria.macros.derive._
import sangria.marshalling.circe._
import scala.concurrent.ExecutionContext.Implicits.global
import io.circe.generic.auto._

// Some basic data structures

timruffles

In many production systems you'll want to have one module capable of talking to many potential implementations of a collaborator module (e.g a in memory cache, a redis-based cache etc). While testing it's useful to control which module the module under test is talking to.

Here are the approaches I can see. The two points that seem to divide the approaches are their tool-ability (dialyzer) and their ability to handle stateful implementations (which need a pid).

Passing modules

Modules are first class, so you can pass them in. Used in EEx, where passed module must implement a behaviour.

evancz

// initialize the Shanghai component which keeps track of
// shipping data in and out of the Port of Shanghai.
var shanghai = Elm.worker(Elm.Shanghai, {
    coordinates:[0,0],
    incomingShip: { name:"", capacity:0 },
    outgoingShip: ""
  });

function logger(x) { console.log(x) }