[test] testing protected/private methods out of test suits
Hello boost-users, I tried to test protected/private class methods by declaring the test-case-class as a friend of the class-to-test. The test-case-class is defined by the macro BOOST_FIXTURE_TEST_CASE(T, F). That works fine as long as I encapsulate the test-case with BOOST_AUTO_TEST_SUITE(suite_name) and BOOST_AUTO_TEST_SUITE_END(). I'm not able to define the correct friend declaration, cause the compiler . Can someone give me hint, please? the code looks like this: // test-case-class.cpp namespace foo { namespace bar { BOOST_AUTO_TEST_SUITE(suite_name) struct F { class-to-test class_to_test_instance; } . . . BOOST_FIXTURE_TEST_CASE(test-case-class, F) { F.class_to_test_instance.i; . . . } . . . BOOST_AUTO_TEST_SUITE_END() }} class-to-test.cpp namespace foo { namespace bar { . . . class class-to-test { public: friend struct test-case-class; // that's wrong // No access to protected member i friend struct suite_name::test-case-class; // this is wrong, too: compiler error, can't find foo::bar::suite_name, .... protected: int i; . . . }; }} greetz, modbom -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx
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 tried to test protected/private class methods by declaring the test->case-class as a friend of the class-to-test.
Why are you trying to do this? In test driven development you should be testing the interfaces not the internals, from Wikipedia: "Some may object that using strict black box testing does not provide access to private data and methods. This is intentional; as the software evolves, you may find the implementation of a class changes fundamentally. Remember a critical step of test-driven development is to refactor. Refactoring may introduce changes which adds or removes private members, or alters an existing member's type. These changes ought not break existing tests. Unit tests that exploit glass box testing are highly coupled to the production software; changing the implementation of a class or module may mean you must also update or discard existing tests, things which should never have to occur. For this reason, glass box testing must be kept to the minimum possible. White box testing should never be used in test-driven development." Your private and protected methods should all be tested via calls to the public methods. ****************************************************************************** "This message and any attachments are solely for the intended recipient and may contain confidential and privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you." Interactive Transaction Solutions Ltd (2473364 England) Registered Office: Systems House, Station Approach Emsworth PO10 7PW ********************************************************************** Ce message �lectronique contient des informations confidentielles � l'usage unique des destinataires indiqu�s, personnes physiques ou morales. Si vous n'�tes pas le destinataire voulu, toute divulgation, copie, ou diffusion ou toute autre utilisation de ces informations, est interdite. Si vous avez re�u ce message �lectronique par erreur, nous vous remercions d'en avertir son exp�diteur imm�diatement par email et de d�truire ce message ainsi que les �l�ments attach�s. Interactive transaction Solutions SAS- France (RCS Pontoise : 489 397 877) Si�ge social : Parc Saint Christophe, 10, Avenue de l�Entreprise 95865 Cergy-Pontoise Cedex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
I tried to test protected/private class methods by declaring the test->>case-class as a friend of the class-to-test.
Why are you trying to do this? In test driven development you should be >testing the interfaces not the internals, from Wikipedia:
Apologies, you 'should', of course, be doing whatever you think best, however is it not possible to test your private methods via the public interface? ****************************************************************************** "This message and any attachments are solely for the intended recipient and may contain confidential and privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you." Interactive Transaction Solutions Ltd (2473364 England) Registered Office: Systems House, Station Approach Emsworth PO10 7PW ********************************************************************** Ce message �lectronique contient des informations confidentielles � l'usage unique des destinataires indiqu�s, personnes physiques ou morales. Si vous n'�tes pas le destinataire voulu, toute divulgation, copie, ou diffusion ou toute autre utilisation de ces informations, est interdite. Si vous avez re�u ce message �lectronique par erreur, nous vous remercions d'en avertir son exp�diteur imm�diatement par email et de d�truire ce message ainsi que les �l�ments attach�s. Interactive transaction Solutions SAS- France (RCS Pontoise : 489 397 877) Si�ge social : Parc Saint Christophe, 10, Avenue de l�Entreprise 95865 Cergy-Pontoise Cedex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
Am Mo September 22 2008 10:58:30 schrieb Patrick Loney:
I tried to test protected/private class methods by declaring the
test->>case-class as a friend of the class-to-test.
Why are you trying to do this? In test driven development you should
be >testing the interfaces not the internals, from Wikipedia:
Apologies, you 'should', of course, be doing whatever you think best, however is it not possible to test your private methods via the public interface?
You mean by deriving my class_to_test with derived_class and wraping the protected class_to_test::method_to_test by a public method in derived_class? That's possible, but I didn't like that. Because if I'm precise I only test the public method of derived_class that way ;-) But if nothing works, I will do that. To return to your previous posting: I try to do my best and test only public method. But sometimes it's very hard, especially for complex protected methods. Either you use the way descripted above or you move the method to a helper class. Both alternatives are not elegant I think. greetz Manuel
*************************************************************************** ***
"This message and any attachments are solely for the intended recipient and may contain confidential and privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you."
Interactive Transaction Solutions Ltd (2473364 England)
Registered Office: Systems House, Station Approach Emsworth PO10 7PW
**********************************************************************
Ce message électronique contient des informations confidentielles à l'usage unique des destinataires indiqués, personnes physiques ou morales. Si vous n'êtes pas le destinataire voulu, toute divulgation, copie, ou diffusion ou toute autre utilisation de ces informations, est interdite. Si vous avez reçu ce message électronique par erreur, nous vous remercions d'en avertir son expéditeur immédiatement par email et de détruire ce message ainsi que les éléments attachés.
Interactive transaction Solutions SAS- France (RCS Pontoise : 489 397 877)
Siège social : Parc Saint Christophe, 10, Avenue de lEntreprise 95865 Cergy-Pontoise Cedex
______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
AMDG trashing@gmx.net wrote:
To return to your previous posting: I try to do my best and test only public method. But sometimes it's very hard, especially for complex protected methods. Either you use the way descripted above or you move the method to a helper class. Both alternatives are not elegant I think.
I suppose that you could add class C { friend class C_test_access; }; and define C_test_access in the tests, with only static forwarding functions. In Christ, Steven Watanabe
You mean by deriving my class_to_test with derived_class and wraping the >protected class_to_test::method_to_test by a public method in derived_class?
No, I just meant testing the public members with all the parameters required to fully test the private/protected methods as they are used by your class. If someone writes a derived class that uses one of your protected methods in a different way then they need to write test cases to ensure that the method is producing the results they want. I don't think your test cases can anticipate how your protected methods will be used by derived classes. On the other hand this is a bit simplistic but I think it would be better than #defining protected to public? Class classToTest { Public: #ifdef UNIT_TESTING testingAccessToMethodToTest() { methodToTest() ) } #endif UNIT_TESTING Protected: methodToTest() {} } ****************************************************************************** "This message and any attachments are solely for the intended recipient and may contain confidential and privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you." Interactive Transaction Solutions Ltd (2473364 England) Registered Office: Systems House, Station Approach Emsworth PO10 7PW ********************************************************************** Ce message �lectronique contient des informations confidentielles � l'usage unique des destinataires indiqu�s, personnes physiques ou morales. Si vous n'�tes pas le destinataire voulu, toute divulgation, copie, ou diffusion ou toute autre utilisation de ces informations, est interdite. Si vous avez re�u ce message �lectronique par erreur, nous vous remercions d'en avertir son exp�diteur imm�diatement par email et de d�truire ce message ainsi que les �l�ments attach�s. Interactive transaction Solutions SAS- France (RCS Pontoise : 489 397 877) Si�ge social : Parc Saint Christophe, 10, Avenue de l�Entreprise 95865 Cergy-Pontoise Cedex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
What about using a friend test fixture class to allow data access. See example below: AClass.hpp: namespace Test { class AClass; } class AClass { friend class Test::AClass; ... }; Test/AClass.hpp: #include "AClass.hpp" namespace Test { class AClass { // test cases referencing private ::AClass data }; } But then derived classes will have to re-test the protected functions. Ideally there should be minimal protected functions. Cheers, spider. On Tue, Sep 23, 2008 at 7:10 PM, Patrick Loney < Patrick.Loney@interactivets.com> wrote:
You mean by deriving my class_to_test with derived_class and wraping the >protected class_to_test::method_to_test by a public method in derived_class?
No, I just meant testing the public members with all the parameters required to fully test the private/protected methods as they are used by your class. If someone writes a derived class that uses one of your protected methods in a different way then they need to write test cases to ensure that the method is producing the results they want. I don't think your test cases can anticipate how your protected methods will be used by derived classes.
On the other hand this is a bit simplistic but I think it would be better than #defining protected to public?
Class classToTest { Public: #ifdef UNIT_TESTING testingAccessToMethodToTest() { methodToTest() ) } #endif UNIT_TESTING Protected: methodToTest() {} }
******************************************************************************
"This message and any attachments are solely for the intended recipient and may contain confidential and privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you."
Interactive Transaction Solutions Ltd (2473364 England)
Registered Office: Systems House, Station Approach Emsworth PO10 7PW
**********************************************************************
Ce message électronique contient des informations confidentielles à l'usage unique des destinataires indiqués, personnes physiques ou morales. Si vous n'êtes pas le destinataire voulu, toute divulgation, copie, ou diffusion ou toute autre utilisation de ces informations, est interdite. Si vous avez reçu ce message électronique par erreur, nous vous remercions d'en avertir son expéditeur immédiatement par email et de détruire ce message ainsi que les éléments attachés.
Interactive transaction Solutions SAS- France (RCS Pontoise : 489 397 877)
Siège social : Parc Saint Christophe, 10, Avenue de l'Entreprise 95865 Cergy-Pontoise Cedex
______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
[I'm just catching up on two months of unchecked e-mail.] On Sep 18, 2008, at 3:26 AM, M. Siebeneicher wrote:
I tried to test protected/private class methods by declaring the test-case-class as a friend of the class-to-test. The test-case- class is defined by the macro BOOST_FIXTURE_TEST_CASE(T, F). That works fine as long as I encapsulate the test-case with BOOST_AUTO_TEST_SUITE(suite_name) and BOOST_AUTO_TEST_SUITE_END().
I'm not able to define the correct friend declaration, cause the compiler . Can someone give me hint, please?
the code looks like this: [TRUNCATE]
The previous responses took three approaches: 1. How to properly declare a friendly test apparatus. 2. How to (temporarily) mess with the definitions of "protected" and "private" to make them publicly accessible, with various compiler- dependent degrees of success. 3. Question on why you're doing this and come up with workarounds. I'm going to go on track 3 myself. Protected and private methods ultimately exist to support public ones. Therefore NO code should exist in non-public methods that can't be activated through some combination of public method calls (including friends). This statement should definitely be followed for testing private methods. Protected ones have a slight problem in that a derived class could potentially use said methods with arbitrary sets of parameters that none of the public methods can do (falling within pre-conditions, of course). If your public methods cannot fully exercise some protected ones, then you need to create a custom derived class for testing. This is especially important if some private method code can only be accessed when a protected method is called with unusual parameters. For any method, no matter the accessibility level, make sure to do additional testing with derived classes using overrides if a method either is virtual or could call (directly or indirectly) a virtual method. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
participants (7)
-
Daryle Walker -
M. Siebeneicher -
Patrick Loney -
Robert Mecklenburg -
spiderlama -
Steven Watanabe -
trashing＠gmx.net