Re: Unit Testing Frameworks (was Re: Singletons)
On 12/28/2012 10:34 PM, Dave Abrahams wrote:
This is the nub of the argument, but nothing posted so far backs up
the assertion. The preceding posts all demonstrate the use of
different loggers.
It seems self-evident to me, but I'll try to explain anyway.
* Most singletons are designed not to allow arbitrary lifetime
management at all, so you can only have one during the life of the
executable
Not really. One important part of this thread was exactly on this.
Singleton is a *design* pattern, that is about summoning an object that
*behaves* as the same throughout the specified time-region, and every
client can build on that fact.
The rest is implementation detail. It may really a single instance be
created early and kept for long, or may use any other magic.
And importantly it is about the designated object, not its class, so the
usual struggle to make a "singleton class" that focuses to *prevent*
multiple instances creation are way off track. And are only good to
shadow those working on the original goal for special cases.
For the big majority of the cases the simplest way works: you have a
regular class that does the job, and a global function deals with the
summoning stuff. Separating the responsibilities as in the book -- and
allowing different combinations.
Also, the "specified time-region" is not direct-mapped to "life of the
executable". IME the latter is pretty rare case, the most usual period
is after-appinit-is-done through until-shutdown-initiated. (Extending
that needs special treatment, careful planning and documentation;
fortunately not needed that often.)
And there's no problem to set it 'from start to finish of that test
case' either.
* In any case, only one instance of a singleton can exist at a given
time, by definition
Of the singleton object, sure -- but that poses no problems at all. You
keep thinking in the must-be-a-class terms.
But even with a class packed solution it need not be a testing problem,
as you can force creation at start of case and erase it at the end of
it. Next case will start afresh.
The only test scenario hurt is the one we already discussed, if you
launch the cases in multiple threads instead of sequentially.
* Therefore if you have two tests that need to talk to different loggers
they either must be in separate executables (in the first case) or at
least can't run in separate threads (in the second case).
What am I missing?
The last point is correct formally. But IME it is hardly a practical
problem, because:
* when the program is generally not thread-aware, MT tests tests will
not fit the picture
* when the program is thread-aware, and uses singletons, those will be
even more thread-aware. and though you can not separate the instances
the test will do its job fine
I agree that you can find a few test cases where you actually look into
the singleton's state as well, and need to use the original, but it is a
small minority. That can be "packaged" separately for either build or
just execution.
* thinking of systems I saw that had actual tests, there were many units
many dozens of executables even for small LOC ones. It looks impractical
to struggle multithreading on this level rather than on the suite level.
* as already mentioned IME singletons are normally found in Application
part and rare in Library parts (for a ton of trivial reasons). And
application testing is way tricky in its own right let alone making it
parallel internally.
So in summary, I don't mind an assertion like 'singletons, in SOME rare
cases can hurt a MULTITHREADED approach of testing', but extrapolating
that to a general test-hindering is IMNSHO just @#$@!#$!@.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]