Re: Unit Testing in C++
On Jun 24, 4:43 am, earthwormgaz <earthworm...@googlemail.com> wrote:
I've tried to get around this by not building an object file for class
A, but using A.obj which has already been built, but linking it
against my mock versions of B.obj and C.obj. This would work, except
that C.h defines C::~C(), and so A.obj ends up with a definition of
C::~C() in it, and I get multiply defined symbol link errors. I could
make sure all method definitions are in cpp files, but often having a
getter or setter inline is perfectly sensible.
How do people get around these issues of mocking out classes
effectively from a build system point of view?
It sounds like your problem could be fixed object by more carefully
controlling the visiblity of each module's symbols.
There should not be any problem with A.obj having linked in a copy of
C's destructor. The problem occurs when A.obj then -exports- C's
destructor (that it imported from C.obj) for other modules to link
against. So with A.obj and C.obj both claiming to have C's destructor,
the linker does not know which one to choose - and reports an error.
I'm assuming that each .obj file is configured to export of all of its
(global) symbols. In that case, I would reconfigure the .obj projects
to export no symbols by default. Next, I would then label (in the
source code), each of A's (public) methods with the appropriate
attribute for exporting (probably "dllexport" or similar). So, by
having A.obj, B.obj and C.obj exporting only the public functions of
their respective classes - there should be no more multiply-defined
symbols and the unit test modules and the program modules should link
together successfully.
Greg