On Jun 25, 5:08 pm, Noah Roberts <u...@example.net> wrote:
> Ian Collins wrote:
> > Noah Roberts wrote:
> >> earthwormgaz wrote:
> >>> I'd rather not have to change the original source code
> >>> just to accommodate mocking for unit tests. Is that
> >>> actually what most people end up doing?
> >> I try not to but sometimes it's the only way. It certainly
> >> points to strong coupling when you have to trick your
> >> source into allowing a mock, and maybe you want to do
> >> something about that, but sometimes that's just the way it
> >> is.
> > It's seldom if ever the only way. It might be the easy way,
> > bit it is definitely a design smell.
> I never said it wasn't. In legacy code issues (where complete
> product lines where developed and designed without unit
> testing) it can certainly be the only way to get something
> under test. At times like that you absolutely have to cut
> corners or you can be left refactoring HUGE chunks of code
> without the support of unit tests.
That's a different issue. If you're dealing with legacy code,
or even external code (like Solaris, or Linux

), then you
sometimes have to resort to mock functions: you may design your
socket wrapper class to support simulating all possible errors,
but Posix didn't take that into consideration when it designed
its socket interface, and if you're going to test your socket
wrapper class, you'll need to provoke all possible error returns
from the system functions---which probably means linking in a
mock library.
The original poster spoke of a problem due to three headers
being in the same directory. IMHO, either the three headers are
so closely related that they form a single unit, or they belong
in different directories. And units should be very loosely
coupled, only depending on lower units in the hierarchy, which
they can "assume" correct and tested. (As I said, you don't
create a mock std::vector.) In an ideal world, of course.
--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34