Tag Archives: hello world

Why wait forever for the tests? Fast tests of slow software.

Time is volatile

Imagine writing a cron-like functionality that should produce some side-effect, such as cleanup. The intervals between such actions might be quite long. How does one test that? One can surely reason about the software, but given a certain complexity, test should be written, proving that certain important scenarios work as intended.

It’s common that software depends on time flow as dictated by the physical time flow, reflected via some clock provider. However, resetting the time to a year ahead won’t make the CPU work faster and make all the computations it should have performed within that year. A clock is also a volatile component that can be manipulated, thus if time is an issue, it’s probably a good idea not to depend on it directly, following the Stable Dependencies Principle and the Dependency Inversion Principle.

Luckily, there is an abstraction for time, at least in Reactive Extensions (Rx), which is the Scheduler.

Slow non-tests

Here’s a slow Groovy non-test, waiting for some output on the console using RxGroovy:

import rx.*
import java.util.concurrent.TimeUnit

def observable = Observable
	.just(1)
	.delay(5, TimeUnit.SECONDS)

observable.subscribe { println 'ah, OK, done! Or not?' }

Observable
	.interval(1,TimeUnit.SECONDS)
	.subscribe { println 'still waiting...' }

println 'starting to wait for the test to complete ...'

observable.toBlocking().last()

Running it produces the following slow-ticking output:

oldnontest 1

Interpreting such tests without color can be somewhat challenging 2.

Fast tests

Now let’s test something ridiculous, such as waiting for a hundred days using Spock. Luckily, RxJava & RxGroovy also do implement the test scheduler, thus enabling fast tests using virtual time:

import spock.lang.Specification

import rx.Observable
import rx.schedulers.TestScheduler
import java.util.concurrent.TimeUnit


class DontWaitForever extends Specification {
    def "why wait?"() {
        setup:
            def scheduler = new TestScheduler()

            // system under test: will tick once after a hundred days
            def observable = Observable
                .just(1)
                .delay(100, TimeUnit.DAYS, scheduler)
            def done = false

        when:
            observable.subscribe {
                done = true
            }

            // still in the initial state
            done == false

        and:
            scheduler.advanceTimeBy 100, TimeUnit.DAYS

        then:
            done == true
    }
}

fasttest 3

just checking, advancing the time by 99 days results in a failure:

just_checking

Delightful, groovy colors!

Source

github.com/d-led/dont_wait_forever_for_the_tests

  1. Caputured with the wonderful pragmatic tool LICEcap by the Reaper developers
  2. Here, the ‘still waiting’ subscription is terminated after the first subscription ends. Try exchanging the order of the subscribe calls.
  3. Building using Gradle

Deterministic Testing of Concurrent Behavior in RxCpp

A Retrospective

After getting inspired by The Reactive Manifesto, it is hard not to get excited about Reactive Extensions. Such excitement has lead to a series of hello-world articles and some code examples. While Reactive Extensions take over the programming world in C#, Java and JavaScript, it seems, the world of C++ is slow to adopt RxCpp.

The new ReactiveX Tutorial link list is a great place to start learning and grokking. This article is an attempt to bring RxCpp closer to C++ developers who might not see yet, how a reactive programming model might help writing better, more robust code.

Testing concurrency with RxCpp

A previous article showed how to test ViewModels in C# by parameterizing the ViewModels with a scheduler. In a UI setting, the scheduler usually involves some kind of synchronization with the GUI thread. Testing keystrokes arriving at certain speed would require some effort to simulate events, probably leading to brittle tests. With the scheduler abstraction, the concurrent behavior of a component is decoupled from physical time, and thus can be tested repeatedly and very fast. This was the C# test:

(new TestScheduler()).With(scheduler =>
{
    var ticker = new BackgroundTicker(scheduler);

    int count = 0;
    ticker.Ticker.Subscribe(_ => count++);
    count.Should().Be(0);

    // full control of the time without waiting for 1 second
    scheduler.AdvanceByMs(1000);
    count.Should().Be(1);
});

Show Me The Code

Without further ado, the C++ version is not very far from the C# version. In a simple test, we can parameterize a sequence of integer values arriving at specified intervals (a ticker) with a coordination (why coordination and not scheduler, read in the RxCpp developer manual:

auto seq = rxcpp::observable<>::interval(
            std::chrono::milliseconds(1),
            some_scheduler
);

The deterministic test scheduler API is currently available through a worker created on the test scheduler:

auto sc = rxcpp::schedulers::make_test();
auto worker = sc.create_worker();
auto test = rxcpp::identity_same_worker(worker);

The rest should read like English:

int count = 0;

WHEN("one subscribes to an observable sequence on the scheduler") {
  auto seq = rxcpp::observable<>::interval(
              std::chrono::milliseconds(1),
              test // on the test scheduler
             ).filter([](int i) { return i % 2; });

  seq.subscribe([&count](int){
    count++;
  });

  THEN("the sequence is not run at first") {
    worker.sleep(2 /* ms */);

    CHECK(count == 0);

    AND_WHEN("the test scheduler is advanced manually") {

      THEN("the sequence is run as expected") {
        worker.advance_by(8 /* ms */);
        CHECK(count == 5);
      }
    }
  }
}

The full test can be seen @github, and is built on Travis CI

RxCpp 2

RxCpp 2 and API

The last article on rxcpp was based on a now obsolete version of RxCpp. The key contributor to the library, Kirk Shoop, has kindly provided a rewrite based on the newer, 2.0 API of the library: see the pull request, upon which this article is based.

Since the first article, the project has been enriched with somewhat more readable GIVEN/WHEN/THEN-style tests using Catch 1.

Still Ticking: Scheduler and Coordination in RxCpp 2

The previous articles give examples of managing periodic events, such as ticker ticks and measurements in c++. The following example creates an event loop that will be used for coordinated output of various events to the console:

auto scheduler = rxcpp::schedulers::make_same_worker(
    rxcpp::schedulers::make_event_loop().create_worker()
);

auto coordination = rxcpp::identity_one_worker(scheduler);

One such sequence of events is some kind of measurement 2

auto measure = rxcpp::observable<>::interval(
        // when to start
        scheduler.now() + std::chrono::milliseconds(250),
        // measurement frequency
        std::chrono::milliseconds(250),
        coordination)
    // take Hz values instead of a counter
    .map([&FM](int) { return FM.Hz(); });

auto measure_subscription = measure
    .subscribe([](int val) {
        std::cout << val << std::endl;
    });

Why didn’t it tick?

If this code were the end of the main program, there wouldn’t be any observable ticks, as all the objects would be destroyed before the first scheduled event. To see the code in action, we shall wait for some condition that will change when we’re done. This step is not necessary if there’s a GUI toolkit event loop that keeps objects alive, but it has to be simulated for a console example.

To demonstrate the subscription change and wait for some time, we’ll wait twice for an atomic variable to become zero:

std::atomic<long> pending(2);

...

// after all subscriptions defined
while (pending) {
    sleep(1000); // wait for ticker and measure to finish
}

Tick and Stop

The other ticker will have another period, will only tick 10 times, and then decrement the pending counter:

auto ticker = rxcpp::observable<>::interval(
    scheduler.now() + std::chrono::milliseconds(500),
    std::chrono::milliseconds(500),
    coordination);

ticker
    .take(10)
    .subscribe([](int val) {
        std::cout << "tick " << val << std::endl;
    },[&](){
        --pending; // take completed the ticker
    });

Now, we can schedule the termination of the measurement (decrement pending) subscription halfway through the 10-tick run. This scheduling is done on the same scheduler that is running all the subscriptions:

scheduler.create_worker().schedule(scheduler.now() + std::chrono::seconds(2), 
    [&](const rxcpp::schedulers::schedulable&) {
        std::cout << "Canceling measurement ..." << std::endl;
        measure_subscription.unsubscribe(); // cancel measurement
        --pending; // signal measurement canceled
    });

The result:

63
tick 1
63
61
tick 2
63
61
tick 3
63
62
Canceling measurement ...
tick 4
tick 5
tick 6
tick 7
tick 8
tick 9
tick 10

Thanks, Kirk & other library contributors!

Code @ github

Next: deterministic testing of concurrent behavior

  1. i.e. create.cpp
  2. Observe the convergence of the API towards the C# version.

No Events: ReactiveUI Windows Forms MVVM-Style

Review

designed using http://viperneo.github.io/winforms-modernui/

This is the next post in the series, looking first at Reactive Extensions (RX) to simplify writing Windows Forms UI logic, then using a viewmodel shared between a WPF gui implementation and a rewritten WinForms version using ReactiveUI, stopping at a short article on testing the viewmodels.

passedtest

ReactiveUI News

ReactiveUI API has been quite volatile for the last year, and this series is in need of an update1. A CodeProject author gardner9032 published a nice teaser article, showing the ReactiveUI mechanism for writing simplified Viewmodel-View bindings 2, which serves as primary trigger for this post.

There’s plenty of news and updated articles on Paul Betts’ log, providing a good resource for updates on the API. Phil Haack’s blog is also a superb resource for explanations and commentaries on the use of ReactiveUI in real-world applications.

The ReactiveUI project is quite active, as the community seems to have grokked the jist of it, while the list of supported platforms has become more than convincing.

Getting rid of events

The enabling feature of ReactiveUI is writing declarative UI glue code, and if the viewmodels are based on Reactive Extensions, then declarative C# style can be used throughout the project. The previous ReactiveUI Windows Forms examples converted an event sequence into an observable sequence of values. In this example, that will be accomplished conveniently by the ReactiveUI WinForms lbrary. The viewmodels also contained some imperative code. For this article, the viewmodels will not be reused from the previous articles, but written from scratch.

ViewModel

s. code

The viewmodel’s task is the same: something is ticking in the background, while words are counted in the input text asynchronously, and the calculation is throttled to 0.5 seconds. The viewmodel boilerplate is simplified using ReactiveUI.ReactiveObject.

Output (read-only) properties

The ReactiveUI-way of creating output properties is through ObservableAsPropertyHelper.

private readonly ObservableAsPropertyHelper<string> backgroundTicker;
public string BackgroundTicker
{
    get
    {
        return backgroundTicker.Value;
    }
    //...
}

The constructor of the viewmodel receives an IScheduler for scheduling on the correct thread, and an IObservable, which will be a stream of input from the view. Observe the ToProperty helper:

public MyViewModel(IScheduler scheduler, IObservable<string> input)
{
    Observable.Interval(TimeSpan.FromSeconds(1))
        .ObserveOn(scheduler)
        .Select(_ => DateTime.Now.ToLongTimeString())
        .ToProperty(this, x => x.BackgroundTicker, out backgroundTicker);
    //...
}

Word counting logic is implemented in a similar fashion by transforming the incoming stream of strings.

View

s. code

To remove yet more boilerplate code, WinForms Form specialization implements the ReactiveUI.IViewFor interface. This allows for largely simplified run-time and compile-time checked bindings, avoiding using strings for property names. The implementation is straightforward, and pays off once the views become more complex than this example:

IViewFor

public MyViewModel VM { get; private set; }

object IViewFor.ViewModel
{
    get { return VM; }
    set { VM = (MyViewModel)value; }
}

MyViewModel IViewFor<MyViewModel>.ViewModel
{
    get { return VM; }
    set { VM = value; }
}

Bindings

None of the controls in the designed WinForm have wired events or bindings set from the designer. The glue code is reduced to instantiating the viewmodel …

VM = new MyViewModel(
    new System.Reactive.Concurrency.ControlScheduler(this),
    this.WhenAnyValue(x => x.inputBox.Text)
);

… and declaring the bindings3 4.

this.Bind(VM, x => x.BackgroundTicker, x => x.tickerBox.Text);
this.Bind(VM, x => x.WordCount, x => x.wordCountBox.Text);

Source

@github

  1. See ReactiveUI Design Guidelines
  2. see article @CodeProject
  3. The ReactiveUI WinForms implementation seems not to support fully read-only fields using default bindings yet, hence an empty setter in the viewmodel
  4. The scheduler is from Windows Forms helpers

A C++ Background Ticker, now with Rx.cpp

Finally, Rx.cpp

Some time ago I have written that I didn’t have enough patience to recreate the background ticker example in C++ using Rx.cpp. Since then the Rx.cpp project seems to have grown out of the spike phase, and even has a native NuGet package. It has also gone multiplatform (Windows, OSX and Linux): observe the green Travis-CI Button.

Update: new blog post, discussing RxCpp v2 and testing using the test scheduler.

A simple console ticker

As in .Net, Reactive Extensions provide a simple way to process streams of data asynchronously, while keeping the concurrency-related code declarative and thus readable. Here’s a simple ticker in the console which runs asynchronously to the main thread:

auto scheduler = std::make_shared<rxcpp::EventLoopScheduler>();
auto ticker = rxcpp::Interval(std::chrono::milliseconds(250), scheduler);

rxcpp::from(ticker)
	.where([](int val) { return val % 2 == 0; })
	.take(10)
	.subscribe([](int val) {
		std::cout << "tick " << val << std::endl;
	});

std::cout << "starting to tick" << std::endl;

resulting in something like:

starting to tick
tick 0
tick 2
tick 4
tick 6
tick 8
...

where the ticks appear once in 250 milliseconds.

Throwing away code

The PPL example was simulating polling a sensor and printing the value. It had an error-prone and buggy ad-hoc implementation of an active object, ticking at predefined intervals. This can be now happily thrown away, as Rx allows a cleaner concurrency control and testability using schedulers, and implements a timed sequence: Interval.

Preconditions

FrequencyMeter FM;
auto scheduler = std::make_shared<rxcpp::EventLoopScheduler>();

The scheduler will be used for all subscriptions.

The tickers

The first one:

auto measure = rxcpp::Interval(std::chrono::milliseconds(250),scheduler);
auto measure_subscription = rxcpp::from(measure)
	.subscribe([&FM](int val) {
		std::cout << FM.Hz() << std::endl;
	});

where measure_subscription is a rxcpp::Disposable for subscription lifetime control.

And the other one:

auto ticker = rxcpp::Interval(std::chrono::milliseconds(500), scheduler);
rxcpp::from(ticker)
	.take(10)
	.subscribe([](int val) {
		std::cout << "tick " << val << std::endl;
	});

where you can observe the LINQ-style filter take

Managing subscriptions

In the PPL example, one could start and stop the ticker. However, in Rx.cpp this can be simply modeled by disposable subscriptions. Hence, after some kind of sleeping, the measurement can be stopped:

sleep(2000);
std::cout << "Canceling measurement ..." << std::endl;
measure_subscription.Dispose(); // cancel measurement

Resulting in similar output:

60
63
tick 0
61
62
tick 1
63
63
tick 2
62
60
tick 3
Canceling measurement ...
tick 4
tick 5
tick 6
tick 7
tick 8
tick 9

Restarting measurement can be done by creating a new subscription.

Why not simply signals/slots?

Almost quoting the Intro to Rx book, the advantages of using Rx over (at least) simple implementations of signal/slot mechanism are:

  • Better maintainability due to readable, composable, declarative code
  • Scheduler abstraction allowing for fast, deterministic, clock-independent tests of concurrency concerns
  • Declarative concurrency through the same scheduler abstraction
  • LINQ-like composition and filtering of event streams
  • Easy subscription control via disposables
  • Completion and exception handling built-in in the Observer concept

Code

@GitHub

Corrections, suggestions and comments are welcome!

Update 26.6.2014: There’s been a new release of Rx.cpp on nuget, and Kirk Shoop pushed a pull request, upgrading the project and the api usage to Rx.cpp 2.0.0. There have been some changes, and there are some interesting patterns, which should be blogged about in the near future.

The quest for a c++ Dependency Injection Container library. Part 3, beginning dicpp

Dependency Injection + C++ = dicpp

The first article introduced the example problem – an almost trivial example for dependency injection. One of the implementation classes is mocked within a test to show the resulting implementation configuration flexibility.

Another library in the quest is dicpp. It is somewhat similar to sauce with little twists, hence it required some trial and error to get right after sauce. Dicpp configures the dependencies in code and allows configurable lifetime scopes.

Modules

Modules are, again, similar to sauce’s modules, as they can be simple functions for registering the bindings of interfaces to implementations.

The library uses a slightly intrusive macro that puts a special typedef in the class’ declaration. One constructor is supported and should be split into declaration and definition. The macro for the renderer looks as follows:

class DicppKeyRenderer : public IRender {
public:
	DI_CONSTRUCTOR(DicppKeyRenderer,(std::shared_ptr< IGetKeyValue > m));
...
};

Without changing the existing factory, the default implementations are used:

DicppKeyRenderer::DicppKeyRenderer(std::shared_ptr< IGetKeyValue > m) :
	pimpl ( NewKeyRenderer(m) ) { }

The module with the bindings looks as follows (dicpp_module.cpp):

void dicpp_module( di::registry& r ) {
	r.add( r.type< IGetKeyValue >().implementation<DicppJsonDecoder>() );
	r.add( r.type< IRender >     ().implementation<DicppKeyRenderer>() );
}

Mock and the Singleton scope

To set the mock expectations on an instance of a dependency, one needs to obtain a pointer to that dependency. Once again, the mock implementation of an interface is done via googlemock:

class MockModel : public IModel {
public:
	MOCK_METHOD0(Get, std::string());
};

To obtain the same instance of the mocked IModel as which gets resolved automatically, one can use a dedicated scope, such as the singleton scope. The mock is added to the module in the singleton scope:

void mock_module( di::registry& r ) {
	r.add( r
		.type<IModel>()
		.implementation<MockModel>()
		.in_scope<di::scopes::singleton>() )
	;
}

Configuring the injector

test_dicpp.cpp

The injector is the container of bindings that gets configured by adding modules:

di::injector inj;
inj.install( dicpp_module );
inj.install( mock_module );

Configuring the mock

With the modules “installed” in the injector, the singleton mock instance can be obtained:

auto mock_model = inj.construct_ptr< IModel >();

MockModel* mock_model_ptr = dynamic_cast< MockModel* >(mock_model.get());
ASSERT_TRUE( mock_model_ptr );

EXPECT_CALL(*mock_model_ptr, Get())
	.Times(AtLeast(1))
	.WillRepeatedly(Return("{ \"a\" : 1 , \"b\" : 2 }"));

Logging in dicpp

An interesting feature in dicpp is logging of the library activity. The feature can be overridden or turned off via macro definition. The construction of dependencies can be traced, such as here, slightly shortened :

[DICPP]: Registering: IGetKeyValue with implementation: DicppJsonDecoder in scope: di::scopes::no_scope
[DICPP]: Registering: IModel with implementation: MockModel in scope: di::scopes::singleton
[DICPP]: Registering: MockModel with implementation: MockModel in scope: di::scopes::no_scope
[DICPP]: Constructing: di::type_key<IModel, void>
[DICPP]: Provided type: di::type_key<IModel, void>
[DICPP]: Singleton: constructing: di::type_key<IModel, void>
[DICPP]: Generic constructing IModel with implementation: MockModel
[DICPP]: Completed constructing: di::type_key<IModel, void> with address: 0x7fd0b2600e40
...
[DICPP]: Singleton: returning existing: di::type_key<IModel, void>

As one can see, two bindings are registered for one implementation – the interface and implementation can be resolved at later time.

Summary

The rest of the example is very similar to the first and the second parts of the quest:

auto renderer = inj.construct_ptr< IRender >();
ASSERT_EQ( "a,b", renderer->Render() );

Although the library is very similar to sauce, the binding definition language doesn’t read as fluently as that of wallaroo or sauce. Further articles may elaborate on the outstanding features of either library.

Source: https://github.com/d-led/test-ioc-cpp

Updates

05.11.2014: Removed boost<->std shared_ptr conversions, as dicpp has been updated in the meanwhile

More to come…

The quest for a c++ Dependency Injection Container library. Part 2, some Sauce

Introduction

In Part 1 I have started with a list of C++ dependency injection libraries, and sketched an example problem, solved and tested with the help of Wallaroo. For the second part, Hypodermic should have been in focus, but unfortunately, no version compiled out of the box on MacOS with Clang 1. Hence, the article is about sauce, an inspiration from google-guice.

Dependency Injection using sauce

A little repetition, the example problem contains of 3 interfaces with a linear dependency graph of the implementations. Not to repeat the implementations, and not change the structure of the existing code, simple factories for the default implementations have been exposed, but not the concrete types in the headers, i.e. for the default renderer implementation:

std::shared_ptr< IRender > NewKeyRenderer(std::shared_ptr< IGetKeyValue > model) {
	return std::make_shared<KeyRenderer>(model);
};

Implementations

Simplified, the sauce solution looks as follows. Unlike in Wallaroo, in sauce, the implementations do not need to derive from a common “dependency” class. Any type can be bound to any derived class. The implementation of a renderer for the sauce example just adds a delegation to the original implementation 2:

class SauceKeyRenderer : public IRender {
public:
	SauceKeyRenderer(std::shared_ptr< IGetKeyValue > m) :
	pimpl ( NewKeyRenderer(m) )
	{ }

public:
	virtual std::string Render() {
		//...
		return pimpl->Render();
	}

private:
 	std::shared_ptr< IRender > pimpl;
};

Modules

Modules are containers of bindings of interfaces to their implementations. The easiest way to define a module is to provide a function with the signature void (* module)(sauce::Binder &).

Here’s the self-explaining module:

void render_module(sauce::Binder& b) {
	b.bind<IRender>().to<SauceKeyRenderer(IGetKeyValue&)>();
}

Once again, obviously, the type doesn’t have to leak outside the module due to inversion of control.

Note that the IGetKeyValue dependency of SauceKeyRenderer is injected via the constructor parameter, enabling automatic dependency resolution at later time.

Injectors

Instances of the bound interfaces are obtainable from injectors, which can be constructed from a collection of modules:

sauce::shared_ptr<Injector> injector = Modules()
	.add(render_module)
	.add(decoder_module)
	.add(model_module)
	.createInjector()
;

Resolving the dependencies

The hello-world example of resolving the dependencies is one simple line:

sauce::shared_ptr<IRender> renderer = injector->get<IRender>();

In this case, SauceKeyRenderer will get resolved and two other dependencies will be automatically instantiated and injected (see test_sauce.cpp).

Mocking and singletons

Sauce allows for different lifetime models of the interface instances. Singletons are possible with the concept of scoped injectors, in which, the instances are shared.

For googlemock getting the resolved instance is crucial, since the expectations are bound to an instance of the mocked class. With automatic dependency resolution and no hacks, the interface IModel would resolve to a new instance in the test. Hence, unless a way to use the shared instance lifetime inside the test is found, the mock is implemented trivially without googlemock.

Summary

This article is once again a short intro into the paradigm of another Dependency Injection library sauce. A more elaborate intro can be read in sauce’s tutorial test suite.

Source: https://github.com/d-led/test-ioc-cpp

More to come…

  1. To do in 2014
  2. Efficiency and overhead are not considered in the first place.

The quest for a c++ Dependency Injection Container library. Part 1, Wallaroo Introduction

Introduction

Given the static nature of the C++ type system, the lack of reflection and a platform-independent ABI in native C++, dependency injection doesn’t seem to have fallen into fashion in C++ projects 1. It might be that using the right tool for the right job diminishes the need for dependency injection containers for C++. Nonetheless, I find it worth digging into today’s offer of different libraries. Along the way, several other technologies will shine.

Structure

The resulting code will be constantly updated at https://github.com/d-led/test-ioc-cpp.

The project is expected to compile and run on many desktop platforms with a c++11 compiler. Hence, the makefiles are made with premake and a small helper library.

Mocks are useful when you use dependency inversion, hence the googlemock library will be used for demonstration purposes. Currently, the whole project is a single googletest executable, which is run after each compile.

Some makefiles and a Visual Studio solution are checked in, but can be generated from the premake script anytime.

The plan

The plan is to introduce each DI library superficially at first, and then to dig for feature differences, common patterns and perhaps applicability suggestions. The quest over the available libraries might take some time. The first intent is to give hello world examples of C++ DI libraries in action.

Linux builds and test runs will be performed automatically at https://travis-ci.org/d-led/test-ioc-cpp.

The libraries

A note on memory management

The Single Responsibility Principle is ingrained in all of the Dependency Injection libraries, as the instances are managed via smart pointers, which take up the responsibility of memory management.

Example architecture

An artificial, simple, decoupled architecture is used in the example. The interfaces are as follows:

struct IRender {
	virtual std::string Render() = 0;
	virtual ~IRender() {}
};

struct IGetKeyValue {
	virtual size_t Count() = 0;
	virtual std::string GetKey(size_t pos) = 0;
	virtual std::string GetValue(std::string const& key) = 0;
	virtual ~IGetKeyValue() {}
};

struct IModel {
	virtual std::string Get() = 0;
	virtual ~IModel() {}
};

The names might change during the quest. The expected dependencies are as follows: the renderer needs a model, which is a key-value pair collection, which might be decoded from some kind of data_source, which is here simply a string.

Wallaroo

To start with the quest, let’s look at Wallaroo. This has been the first library that I’ve considered using, and have already written a little walkthrough: lul.

The library has a rather exotic DSL for a DI library, however, it seems to be very well suited for communicating the concepts.

The objects (components) are created within a so-called catalog and have string IDs. When all the necessary objects have been created, they can be wired together with a DSL in the form:

within the catalog, use component_1 as dependency_1 of component_2.

Components == Parts

Let’s see how the components that are usable within Wallaroo are defined. A drawback of Wallaroo can be seen from the start, namely that the components have to be defined intrusively – they have to derive from wallaroo::Part:

class WallarooKeyRenderer :  public wallaroo::Part , public IRender { ... };

The drawback can be somewhat overcome by using the Bridge pattern with composition when refactored. The first implementation here is fully dependent on wallaroo::Part.

The library allows static registration, hence there is no need to expose the type or even a manually written factory of WallarooKeyRenderer:

WALLAROO_REGISTER( WallarooKeyRenderer );

is the registration macro.

Dependencies

Dependencies are called wallaroo::Collaborators. These can be private members:

wallaroo::Collaborator< IGetKeyValue > model;

and must be initialised in the constructor:

WallarooKeyRenderer():
		model( "model", RegistrationToken() )  { }

Then, if wiring the objects succeeds, the collaborators are usable as smart-pointers:

... model->GetKey(pos);

A nice feature in Wallaroo is that it supports constructor parameters. Another one – an initial support for loading plugins from DLLs exists. The configuration of catalogs: instances of objects and their wirings can be loaded from XML or JSON.

Full source: wallaroo_render.cpp

Instantiating objects

There are two implementations of the interfaces: a JSON decoder (using the lightweight single-header picojson library) and a renderer described above. The model can be simply mocked using GMock.

Inside the test (test_wallaroo.cpp) the model can be instantiated as follows.

Given the mock implementation:

class MockModel : public IModel, public wallaroo::Part {
public:
	MOCK_CONST_METHOD0(Get, std::string());
};
WALLAROO_REGISTER( MockModel );

one can now instantiate the mock inside the test and set expectations using the GMock DSL:

catalog.Create("mock model","MockModel");
std::shared_ptr<MockModel> mock_model = catalog["mock model"];
ASSERT_TRUE( mock_model.get() );
EXPECT_CALL(*mock_model, Get())
	.Times(AtLeast(1))
	.WillRepeatedly(Return("{ \"a\" : 1 , \"b\" : 2 }"));

The other objects are instantiated in the fixture:

catalog.Create("renderer", "WallarooKeyRenderer");

and

CreateDecoder("decoder",catalog);

using an example of a factory with inverted control, in case one doesn’t want to let out strings that represent types, but cannot be checked at runtime:

void CreateDecoder(std::string const& name,wallaroo::Catalog& catalog)
{
	catalog.Create(name, WallarooJsonDecoder);
}

That way you neither leak the implementation type, neither its typename string.

Wiring dependencies

Now that the objects are instantiated, they can be wired in code:

wallaroo_within(catalog)
{
	use("decoder").as("model").of("renderer");
	use("mock model").as("data_source").of("decoder");
}

A feature I enjoy in Wallaroo is that you can rewire the dependencies at runtime without creating new objects. That might get you some weird runtime dependencies if your code becomes messy, but if you take care of the quality, that feature might get handy.

When everything is wired up, the test is concluded with

ASSERT_EQ( "a,b", renderer->Render() );

Summary

Wallaroo is an easy to use header-only library, resembling in its use the Multiton Pattern. If instances of the dependencies can be given unique ids, there may be multiple implementations of the same interface, and if the dependencies should be rewired at runtime, wallaroo is a perfect choice.

Updates

05.11.2014: new wallaroo metaphors, +di, +infectorpp

More to come…

  1. Alternative areas: COM & .NET
  2. Can’t compile out of the box on clang yet