test private member function

[PengYu.UT]

Hi,

I want to write a test function to test a class. The class has a
private member function that need to be tested. Although I could
modify the member function as protected or public, I do not want to
modify the class definition. I'm wondering what is the standard way to
test private member functions in a library.

Thanks,
Peng

 

[Simon Wollwage]

Am Sun, 08 Jul 2007 15:38:36 -0700 schrieb (e-mail address removed):

Hi,

I want to write a test function to test a class. The class has a private
member function that need to be tested. Although I could modify the
member function as protected or public, I do not want to modify the
class definition. I'm wondering what is the standard way to test private
member functions in a library.

Thanks,
Peng

you could make a testclass that is a friend of the class that you're
testing. or add a public wrapper method to the tested class.

 

[PengYu.UT]

Am Sun, 08 Jul 2007 15:38:36 -0700 schrieb (e-mail address removed):




you could make a testclass that is a friend of the class that you're
testing. or add a public wrapper method to the tested class.

Hi,

To make the testclass a friend, I still have to change the source code
of the class to be tested (declaring the testclass as a friend),
right?

Could you elaborate more no 'public wrapper method'? Can it access the
private member?

Thanks,
Peng

 

[Simon Wollwage]

Am Mon, 09 Jul 2007 00:01:26 +0000 schrieb (e-mail address removed):

Hi,

To make the testclass a friend, I still have to change the source code
of the class to be tested (declaring the testclass as a friend), right?

Could you elaborate more no 'public wrapper method'? Can it access the
private member?

Thanks,
Peng

For the wrapper method, you have to change the class too.
You HAVE to change it. There's a reason for the "private"-area.
If you still wanna access it without changing the class, you have to
manipulate the vtable. And that's a pain in the ass to do.

 

[Sarath]

Hi,

I want to write a test function to test a class. The class has a
private member function that need to be tested. Although I could
modify the member function as protected or public, I do not want to
modify the class definition. I'm wondering what is the standard way to
test private member functions in a library.

Thanks,
Peng

The intention of Private Functions are, which is to be used by the
public interfaces, or other methods of your class which actually does
the processing, the best way to test your code is that, you can test
the interface or method which using this private function with
different inputs.

CPP Unit is a good framework for Unit Level Testing.

Regards,
Sarath
http://sarathc.wordpress.com/

 

[Dave Steffen]

Am Sun, 08 Jul 2007 15:38:36 -0700 schrieb (e-mail address removed):




you could make a testclass that is a friend of the class that
you're testing. or add a public wrapper method to the tested
class.

[...]

To make the testclass a friend, I still have to change the source code
of the class to be tested (declaring the testclass as a friend),
right?

I'm not sure it's guaranteed to work, but we've used the "#define
private public" hack in our unit tests. It's the only way I know of
to get access to a class' guts for testing purposes *without* changing
the source code.

 

[Kai-Uwe Bux]

Am Sun, 08 Jul 2007 15:38:36 -0700 schrieb (e-mail address removed):

Hi,

I want to write a test function to test a class. The class has a
private member function that need to be tested. Although I could
modify the member function as protected or public, I do not want
to modify the class definition. I'm wondering what is the
standard way to test private member functions in a library.

Thanks,
Peng

you could make a testclass that is a friend of the class that
you're testing. or add a public wrapper method to the tested
class.

[...]

To make the testclass a friend, I still have to change the source code
of the class to be tested (declaring the testclass as a friend),
right?

I'm not sure it's guaranteed to work, but we've used the "#define
private public" hack in our unit tests. It's the only way I know of
to get access to a class' guts for testing purposes *without* changing
the source code.

Formally, that would be undefined behavior in any compilation unit that
includes at least one standard header. See [17.4.3.1.1/2]:

A translation unit that includes a header shall not contain any macros
that define names declared or defined in that header. Nor shall such a
translation unit define macros for names lexically identical to keywords.


Best

Kai-Uwe Bux

 

[Dave Steffen]

Dave Steffen wrote:

Am Sun, 08 Jul 2007 15:38:36 -0700 schrieb (e-mail address removed):

Hi,

I want to write a test function to test a class. The class has a
private member function that need to be tested. Although I could
modify the member function as protected or public, I do not want
to modify the class definition. I'm wondering what is the
standard way to test private member functions in a library.

[...]

I'm not sure it's guaranteed to work, but we've used the "#define
private public" hack in our unit tests. It's the only way I know
of to get access to a class' guts for testing purposes *without*
changing the source code.

Formally, that would be undefined behavior in any compilation unit
that includes at least one standard header. See [17.4.3.1.1/2]:

Yeah, I know. It's a mildly tricky game to play. The first time
I saw it, I thought it was the most horrible thing I'd ever seen.

Interestingly, there was a thread a while back on
comp.lang.c++.moderated a while back about whether or not adding
"#define private public" could actually change the behavior of a
program (assuming the compiler did something reasonable, which isn't
guaranteed by the standard, but is true for popular compilers). The
answer was, IIRC, "Yes, but only if you're doing things you
shouldn't". Overloading member functions with different access
specifiers was the specific example somebody came up with.

So, yeah, not guaranteed to work, not guaranteed portable, but
(practically speaking) workable in some environments. I don't know
of any other way to test private methods *without touching the
source*.