To start with, you should not test private stuff. It is private, so it might change. Binding tests to the private parts makes them harder to change, because of the tests, that should make software easier to refactor and change.

Peter
(Test infected since 1997)

sent from a mobile device so please excuse strange words due to autocorrection.
Peter Sommerlad
peter.cpp_at_[hidden]
+41-79-432 23 32

> On 6 Dec 2020, at 02:57, chibane nadir via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> 
> Hello Team,
> for the purpose of TDD, there is a problem with testing private data members and member functions. some call it black box testing and others do the nasty "#define private public" just to shortcut the visibility of private and protected members to test the classes.
> I suggest to add the feature of "friend namespace" like the following:
>
> namespace XYZ
> {
> // define here your functions and classes
> void test_object_private_data_member_D(object* self,...);
> }
>
> class object
> {
> // private data members, and member functions
> 'sometype' D;
> // public data members, and member functions
>
> // for the purpose of testing this class let's include the members of namespace XYZ as friends so we can access private and protected
> // members of the current class
> private:
> using friend namespace XYZ; // <---- (A)
> };
>
> (A): at this point all the functions and classes defined in the namespace XYZ above will be inserted in the class "object" as friend functions and classes, likewise we will write test cases based on these friend functions and classes since they have access to all
> "object" class no matter what is their visibility (private, protected or public), and avoiding the need to use the nasty macro hack
> '#define private public'
>
> i can show a sample of how i use friend functions to create test cases, for interested people.
>
>
>
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals