+1 to what Peter said, but unfortunately the vast amounts of legacy code
that one has to put unit tests around *before* refactoring it (not to
mention get the refactor funded) mean that we have to have semi-clean
techniques of doing stuff like this.

On Mon, Dec 7, 2020 at 3:48 PM Peter C++ via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> If you end up in such situations, your classes are probably too big and
> try to do too much in one thing.
>
> 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 21:20, chibane nadir <organicoman_at_[hidden]> wrote:
> >
> > @Peter: usually it is true to avoid testing private members, but for the
> sake of preventing a subsequent refactor of public API from creating side
> effects on private members, we need to create test cases with the purpose
> of fixing invariant in our classes. Also if you look at it in different
> manner, private members are part of the logic of the classes, which means
> not testing them could create logic bugs (what i call smart bugs) and
> refactoring them into public member would expose a lot of the guts of the
> implementation.
> >
> > I used to test private members by checking their effects on public
> members (transitive side effects), but i run into a lot of cases where you
> cannot pin point the effect of a private member if the public member
> depends on many of them.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>