Breaking changes in Visual C++ 2015

Chris via Digitalmars-d digitalmars-d at puremagic.com
Mon May 11 02:31:33 PDT 2015


On Friday, 8 May 2015 at 19:45:35 UTC, Walter Bright wrote:
> On 5/8/2015 7:00 AM, Chris wrote:
>> The only drawback is that sometimes the logic of a program 
>> does not allow to
>> test every little bit, especially when handling files is 
>> concerned.
>
> This is an interesting problem, one that I faced with Warp.
>
> The solution was to make the function being tested a function 
> template. Then, in the unit test I replace the 'file' argument 
> to the function with a static array of test data.
>
> The term for it is 'type mocking', and it's fairly well 
> explored territory. What I find most intriguing about it is it 
> results in D programs consisting largely of template functions 
> rather than plain functions.

Hm, I was thinking of something like that, however, it gets more 
and more complicated if you have e.g. a class that uses another 
class etc.

class Data // A singleton
{
   // stores paths to resources etc.
}

class Loader
{
   this()
    this.data = Data.getInstance();
   // Loads files and caches them in memory
}

class Process
{
   // Uses cached data
}

It ain't easy to unit test Process, but even Loader and Data can 
be tricky to unit test, because all of them depend on input from 
the outside.

./runprogram --config="config.json"
> Data.read("config.json")
> Loader.load(resources from config.json)
> Process.use(data loaded)

For cases like this, it's better to have an external test script.


More information about the Digitalmars-d mailing list