Re: [Boost-users] [test] testing protected/private methods out of test suits
M. Siebeneicher writes:
I tried to test protected/private class methods by declaring the test-case-class as a friend of the class-to-test.
Here's what we do to unit test our classes:
#define private public #define protected public #include <common/Blob.hpp>
This makes our unit testing much easier! ;-)
Cheers,
-- Robert
I did this before but now it doesn't work 'cause the class_to_test lies in another library than the test_case_class. greetz, Manuel -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
M. Siebeneicher writes:
#define private public #define protected public
I did this before but now it doesn't work 'cause the class_to_test lies in another library than the test_case_class.
I'm not sure I understand the problem. This hack works regardless of the library decomposition. Visibility is purely a source-code concern, just include #defines and the header declaring the class and you can access anything even if it is in a different library. Cheers, -- Robert
Hi,
I'm not sure I understand the problem. This hack works regardless of the library decomposition. Visibility is purely a source-code concern, just include #defines and the header declaring the class and you can access anything even if it is in a different library.
I don't believe this is true for all compilers or in all cases. For example, changing the member visibility in a class I worked on broke binary compatibility in a library I built with MSVC++ 8. Similar complications may arise when using symbol hiding techniques, such as compiler-specific symbol visibility support, link scripts, etc. HTH, -Ossama -- Disclaimer: The opinions expressed in this e-mail are my own, an in no way represent Intel opinions.
participants (2)
-
M. Siebeneicher -
Othman, Ossama -
Robert Mecklenburg