All right so now I want to show you what exactly the problem with the singleton is.
So we have our Singleton database and let's suppose that we decide to use this database to do some research
and we actually make a new class called a record Finder which is going to find the total population
of several cities whose names you are meant to provide.
So I'm going to have a struct called Singleton record finder because we're going to have a different
record find later on it is going to have just one method which is going to be called Total population.
So the idea is that you provide this method with a vector off the names of the different cities and
it adds up their total population very simple so we have a vector of strings called names.
And here we do fairly obvious stuff so we have the result initially zero and for each of the name in
names all we do is we look it up in a database and add it to the results of results plus equals.
And here is the unpleasant part so we have to use the singleton database so we have to use the singleton
database we have to call it get method and then call get population on the appropriate city here and
then we return results.
So this is actually going to work.
This is completely valid code there is no particular issue with it yet.
But let's suppose that we decide that we want to test the singleton record finder and this is where
all the problems show up.
You can see some testing code that I've got down here below using Google test.
So what is the problem with testing a singleton record finder.
Well let's suppose you decide that you want to test this total population function.
So you write code similar to the following for example so we're going to have a just an ordinary tester
and I'm going to group it under a record finder tests.
And this one is going to be called singleton.
Total population test.
No.
OK.
So the idea is that we're going to instantiate this Singleton record finder.
We're going to call it Aref.
And then what we're going to do is we're going to provide a vector of some names.
I'm going to have a vector of string called names and unfortunately because we are strongly tied to
the real database and there is no way to substitute this database I have to use the values taken from
the actual file.
So here I would look into the file and I would pick may be so cool as well as Mexico City and I would
use these names for my tests so here we go so well and Mexico City that we go.
So I would write my test so I would get the population using the record finder dog.
Total population of the names.
And then I would assert that this is the value I expect.
Now in order to actually write this correctly what I have to do is I have to go into capitals 60 and
I have to get the actual values for the populations off.
So in Mexico City so I have to get real values from what is effectively a production database in our
case.
And I would have to add them up together like so and that is my expected value.
So I'm expecting the population to be precisely this number and I feed in total population in here and
that's my test.
So in order to actually be able to run the tests I'm going to make a new configuration so go into configurations
here I'll make a new one and this time round instead of just having an ordinary executable I'm going
to use Google tests.
So we're going to run all the tests suites and I'm going to leave the defaults as they are and here
we are.
So we can now go ahead and actually run all the vailable tests and see what the output actually is.
All right.
So as you can see our Singleton population test passes we have a c out at some point which is actually
shown here as the output so everything is fine everything is completely OK except that we are strongly
tied to the actual database so we get a production database and we have to expect data from that database.
Now unfortunately what this implies in real terms is that our Singleton total population test is not
a unit test.
It is unfortunately an integration test because all we wanted to do is we wanted to test the singleton
record find that we did not want to test the operation of the database.
But unfortunately due to the strong coupling to the singleton database itself we are unable to untangle
the two.
And as a result we don't really get a proper unit test and this is also quite dangerous because at some
point comp of those XTi might change and we might not have.
So in Mexico City in it in which case this test will become invalid because we're getting the test data
directly from the database.
So surely there is a better way of actually implementing this particular construct so that we can still
use the singleton but if need be we can supply alternative to the singleton implementation with some
dummy data of our own.