Do everything in Java…

[Dicebot via Digitalmars-d]

On Sunday, 7 December 2014 at 13:47:09 UTC, Dicebot wrote:
> However I was not speaking about plain procedural/imperative 
> paradigm as better alternative but functional and generic ones. 
> First one helps with eliminating state in general. Second one 
> allows to use the very same mocks in much more light-weight way 
> because no runtime binding is necessary - no dependency 
> injection stuff and unnecessary interfaces, just using stub 
> policy is enough.

To give some examples from personal experience of what frustrates 
me in typical OOP testing approach:

Imagine we have a simple cache class that internally communicates 
with external dht:

class Cache
{
     private DhtClient client;
     this(string addr) { this.client = new DhtClient(addr); }
}

Now we want to test it which implies adding mock client. 
Canonical way do it is by dependency injection and interface:

class Cache
{
     private IDhtClient client;
     this(IDhtClient client) { this.client = client; }
}

And know what? This just plain sucks. Not only you are now forced 
to modify yoru application code in many places to just comply to 
test-related changes that don't help actual app. You also 
introduce unnecessary interface indirection potentially killing 
inlining opportunities in the process.

Same stuff with policy approach:

class CacheT(DhtClient)
{
     static assert (isDhtClient!DhtClient);

     private DhtClient client;
     this(string addr) { this.client = new DhtClient(addr); }
}

alias Cache = CacheT!DhtClient;

Effectively the same code as sample 1 and makes no difference for 
rest of the application. And how would I test it?

alias TestCache = CacheT!StubDhtClient;

No changes to application, no extra indirections, same effective 
testing coverage. Much better.

And, of course, any utility functions that contain complex logic 
are better moved to free functions so that those can be tested 
with no relation to other code at all.