On Wednesday, 13 May 2015 at 08:26:35 UTC, Kagamin wrote:
On Monday, 11 May 2015 at 09:31:34 UTC, Chris wrote:
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.
That's the reason for IoC design; it's similar to ranges in a
sense that you feed the range with data instead of letting it
figure out where to get that data on its own.
However, the data comes from somewhere outside the program, and
although you can IoC most parts of a program _after_ it's been
fed the data, the initial input section is not easily unit tested
(i.e. unit test in D).
Unit tests only work for the data processing logic inside a unit
after the program has received the data from the outside. But the
initial acquisition of data is outside the scope of these unit
tests. Thus, there are always bits and pieces that cannot be
unit-tested like e.g. loading files.
