On Sun, Dec 6, 2020 at 4:24 AM Peter C++ via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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.
>

I agree with Peter here.
"Refactoring for testability" is definitely a thing. This generally
involves at least two parts, and maybe more:
(1) Make sure all your *dependencies* are *injected*
(2) Make sure all your *functionality* is *exposed*

#2 doesn't have any catchy phrase the way #1 has "dependency injection."
But generally, if your complaint is "Class Foo's `x` method is private, but
I want to test it!" then the obvious fix is to make Foo's `x` method
public. If your complaint is "My unit-testing framework requires `Foo` to
have an operator<<!" then the obvious fix is to give `Foo` an operator<<.
And so on.


Also, notice that if you friend a whole namespace... Namespaces, unlike
classes, are *open*. Physically speaking, anybody in any .cpp file can add
a new member to any namespace. So by friending a namespace you'd be saying
"I don't really care *who* can access my private stuff."
Technically this is already true of `private`, because of this hack I
blogged three days ago
https://quuxplusone.github.io/blog/2020/12/02/unused-private-member/
https://quuxplusone.github.io/blog/2020/12/03/steal-a-private-member/
but I consider that more of a loophole that might one day get *fixed*, if
anyone can figure out how. I definitely wouldn't want to see WG21 put any
effort toward *increasing* the visibility of private members.

–Arthur