Unit Testing in C++

[earthwormgaz]

Hello,

I'm after doing some C++ unit testing, I'm using CppUnit. I like the
look of RudeMocks, but it doesn't work for Solaris/Sparc, so its no
good to me sadly.

So, I have class A, and it uses classes B and C. B and C have methods
A uses, but they're not virtual, and I don't want to hack the code so
that they are just to allow Unit Tests to work. This means that
inheriting from B and C to provide Mock classes is a non starter.

So, I've been trying to provide a mock implementation which is
basically a copy of B or C, but with the guts ripped out and swapped
for mock code. I've then tried to get the code for A, which is under
test, to include the mock versions of the classes headers it depends
on, and link to the objects built from the mock source.

The trouble is, A, B and C are all in the same directory. So, when A
does #include "B.h", it picks up the real version, even if I add the
include path to the mock header. That's because the current directory
takes precedence using VC++, it may well do with GCC and Suncc, which
I'm also using.

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?

[anon]

earthwormgaz wrote:

Hello,

I'm after doing some C++ unit testing, I'm using CppUnit. I like the
look of RudeMocks, but it doesn't work for Solaris/Sparc, so its no
good to me sadly.

So, I have class A, and it uses classes B and C. B and C have methods
A uses, but they're not virtual, and I don't want to hack the code so
that they are just to allow Unit Tests to work. This means that
inheriting from B and C to provide Mock classes is a non starter.

So, I've been trying to provide a mock implementation which is
basically a copy of B or C, but with the guts ripped out and swapped
for mock code. I've then tried to get the code for A, which is under
test, to include the mock versions of the classes headers it depends
on, and link to the objects built from the mock source.

The trouble is, A, B and C are all in the same directory. So, when A
does #include "B.h", it picks up the real version, even if I add the
include path to the mock header. That's because the current directory
takes precedence using VC++, it may well do with GCC and Suncc, which
I'm also using.

you can do this:

#ifdef USE_MOCK_CLASSE S
#include "Bmode.h"
#else
#include "B.h"
#endif

Define USE_MOCK_CLASSE S when you want to do the testing, that is, change
your make file to do it automatically

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?

[earthwormgaz]

On 24 Jun, 13:19, anon <[e-mail] e:

earthwormgaz wrote:

Hello,

I'm after doing some C++ unit testing, I'm using CppUnit. I like the
look of RudeMocks, but it doesn't work for Solaris/Sparc, so its no
good to me sadly.

So, I have class A, and it uses classes B and C. B and C have methods
A uses, but they're not virtual, and I don't want to hack the code so
that they are just to allow Unit Tests to work. This means that
inheriting from B and C to provide Mock classes is a non starter.

So, I've been trying to provide a mock implementation which is
basically a copy of B or C, but with the guts ripped out and swapped
for mock code. I've then tried to get the code for A, which is under
test, to include the mock versions of the classes headers it depends
on, and link to the objects built from the mock source.

The trouble is, A, B and C are all in the same directory. So, when A
does #include "B.h", it picks up the real version, even if I add the
include path to the mock header. That's because the current directory
takes precedence using VC++, it may well do with GCC and Suncc, which
I'm also using.

you can do this:

#ifdef USE_MOCK_CLASSE S
#include "Bmode.h"
#else
#include "B.h"
#endif

Define USE_MOCK_CLASSE S when you want to do the testing, that is, change
your make file to do it automatically

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?

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?

It seems a bit of an 'orrible fix to me.

[Puppet_Sock]

On Jun 24, 9:14*am, earthwormgaz <earthworm...@g ooglemail.comwr ote:
[snip]

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?

So, your plan is to do unit testing without writing any code?

Let us know how that works out.
Socks

[earthwormgaz]

On 24 Jun, 14:33, Puppet_Sock <puppet_s...@ho tmail.comwrote:

On Jun 24, 9:14*am, earthwormgaz <earthworm...@g ooglemail.comwr ote:
[snip]

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?

So, your plan is to do unit testing without writing any code?

Let us know how that works out.
Socks

I'm expecting to write code, in the form of test code, and mock
objects. I'm hoping not to have to change the classes under test just
to test them.

[James Kanze]

On Jun 24, 3:14 pm, earthwormgaz <earthworm...@g ooglemail.comwr ote:

On 24 Jun, 13:19, anon <[e-mail] e:

earthwormgaz wrote:

[...]

The trouble is, A, B and C are all in the same directory.

And if you know the problem, you know the way to fix it.

So, when A
does #include "B.h", it picks up the real version, even if I add the
include path to the mock header. That's because the current directory
takes precedence using VC++, it may well do with GCC and Suncc, which
I'm also using.

you can do this:

#ifdef USE_MOCK_CLASSE S
#include "Bmode.h"
#else
#include "B.h"
#endif

Define USE_MOCK_CLASSE S when you want to do the testing,
that is, change your make file to do it automatically

So you end up testing something different than what you deliver?
Not a good idea, by any means.

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?

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?

It seems a bit of an 'orrible fix to me.

It is.

It's not too clear to me what your deliverables are, but
generally, you should organize your directory structure so that
everything in a given directory can be tested together. If you
need a mock something, then that something should normally be
from a different directory, and not part of the code being
developed in the same directory.

If you need mock object (which you should avoid if
possible---but it isn't always possible on larger projects), you
should arrange for them at the start, putting them in a separate
directory. If the mock objects don't contain any templates or
inline functions, you use the standard header for it, and link
against a locally defined mock library. If B contains templates
or inline functions (both things to be avoided as much as
possible exactly for these sort of reasons), you're probably
stuck with having to compile against a different header file as
well (again, in the mock directory), but beware that this
seriously affects the reliability of your tests, in a negative
way.

To pick up the mock objects, of course, you just add the
appropriate -L (and -I, if you can't avoid it) in the compiler
command (before the other -L or -I).

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[earthwormgaz]

James Kanze wrote:

It's not too clear to me what your deliverables are, but
generally, you should organize your directory structure so that
everything in a given directory can be tested together. If you
need a mock something, then that something should normally be
from a different directory, and not part of the code being
developed in the same directory.

Hmm, I'd come to think that I wanted to mock everything around the
class under test. You seem to be saying mock around the system that
includes the class under test, unless you have to do otherwise.

This is where the unit test/integration test line blurs ...

Say then that classes B and C interface into someLib::D, you'd provide
a mock of D, and use test hooks from that?

[Noah Roberts]

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.

You can't write perfect code. You shouldn't expect it and you shouldn't
try. Just do the best you can under the conditions you find yourself in.

[Noah Roberts]

earthwormgaz wrote:

>
James Kanze wrote:

>It's not too clear to me what your deliverables are, but
generally, you should organize your directory structure so that
everything in a given directory can be tested together. If you
need a mock something, then that something should normally be
from a different directory, and not part of the code being
developed in the same directory.

Hmm, I'd come to think that I wanted to mock everything around the
class under test. You seem to be saying mock around the system that
includes the class under test, unless you have to do otherwise.

I don't think the person you are replying to fully understands the
purpose of unit tests. You definitely do want to test each unit
individually; there should be a test for each public class at the least.
This often involves mock objects.

[James Kanze]

On Jun 24, 5:53 pm, Noah Roberts <u...@example.n etwrote:

earthwormgaz wrote:

James Kanze wrote:

It's not too clear to me what your deliverables are, but
generally, you should organize your directory structure so that
everything in a given directory can be tested together. If you
need a mock something, then that something should normally be
from a different directory, and not part of the code being
developed in the same directory.

Hmm, I'd come to think that I wanted to mock everything around the
class under test. You seem to be saying mock around the system that
includes the class under test, unless you have to do otherwise.

I don't think the person you are replying to fully understands the
purpose of unit tests.

That from you?

You definitely do want to test each unit individually; there
should be a test for each public class at the least.

Hmmm, the name is "unit test", not class test. You want to test
each unit more or less individually. On the other hand, you can
generally consider lower level stuff as "part of the system".
(I never try to mock std::vector, for example. I just suppose
that it works.)

This often involves mock objects.

Not if your code is well designed and well engineered. It
sometimes involves mock objects, but I find that with good
design, it this isn't the case that frequently.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]