C++ unit testing.

[SnaiL]

Hi, guys. I am interested in C++ unit testing. I know only two methods
how to test private class methods.

1) Declare friend class in the code. But I don't like this style
because tests depends on the code.
2) Cheat compiler. We can do it by:

#define private public
#include "..."

Okey-dockey, but we can't cheat linker. I'm using VC++ 7.0... and know
that methods with different access have different name in object
file... so, we can compile, but can't link.

Please share your experience, thanks in advance.

[SnaiL]

Hm... I'm thinking and have some progress...
We can declare empty macros in code and the same macros in tests which
will declare class friends. i.e.:

class A
{
UNIT(A);

public:
....

private:
....
};

When compiling library this macros will be empty, but in tests we will
define:
#define UNIT(A) friend class Test##A

Then we will have friend class and can use it for testing purpose.

Any comments?

[SnaiL]

Hm... It works okay, but when Test class is in the same namespace as
tested class, otherwise it isn't work. How can I declare friend from
another namespace?

[Andrew McDonagh]

SnaiL wrote:

Hi, guys. I am interested in C++ unit testing. I know only two methods
how to test private class methods.

1) Declare friend class in the code. But I don't like this style
because tests depends on the code.
2) Cheat compiler. We can do it by:

#define private public
#include "..."

Okey-dockey, but we can't cheat linker. I'm using VC++ 7.0... and know
that methods with different access have different name in object
file... so, we can compile, but can't link.

Please share your experience, thanks in advance.

In general, unit testing private methods directly is not something that
you should aim to do. If the private method is worthy of additional
testing than it generally means your classes public methods are missing
certain tests.

However, there is another way to view the private method testing
dilemma. If a private method is worthy of testing to this extent, then
it can be an indication that the private method is doing 'too much'. In
other words, the private method is adding additional responsibilities to
its class. Aiming for classes which maintain the Single Responsibility
Principle aid your design in many ways. With this in mind, we can apply
the extractClass refactoring technique. Put simply, we create a new
class and move the private method into it, making the method public in
the process. Now we have just another normal class with a public
method, which can be tested without resorting to compiler/linker/code
tricks. Additional, once we have extracted the class, it can now be
reused by others.

There's been plenty of debate upon this subject, here's a google of
results for you to mull over.

http://www.google.co.uk/search?hl=en...e+Search&meta=

Andrew