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